OO assembly

Index > Main > OO assembly

Goto page Previous 1, 2

Author

Thread

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20519
Location: In your JS exploiting you and your system

revolution 26 Mar 2008, 06:38

daniel.lewis wrote:

forgive me if I'm wrong, but your code would take upwards of 120 cycles to Increment.

It would take ~16 cycles to reload the instruction pipeline through call and then ret. Another cycle for the mov, and 100 cycles because you wrote to memory currently in code cache being executed, which would invoke a cache miss as the code cache block is reloaded with the newly incremented value.

Am I off?

I don't know how many cycles exactly it would take (it would vary by motherboard and CPU) but the general idea is correct.

Putting data in a code segment is particularly inefficient in a modern pipelined/superscalar x86 CPU.

Just for comparison, in the xScale ARM it would make no difference in timing. Once the code is in the prefetch/cache there is no mechanism to detect a change. SMC (and data in code segments) tends to be like that, different systems behave differently.

26 Mar 2008, 06:38

sakeniwefu

Joined: 23 Mar 2008
Posts: 29

sakeniwefu 26 Mar 2008, 11:16

vid wrote:

keeping method pointers right in class object isn't the best idea, it's a waste of memory.

i suggest reading this: http://x86asm.net/articles/oop-from-low-level-perspective/index.html

Hey! Great work!
It was a very interesting read. I hope you expand it.

_________________
Warning: C code found, deleting.

26 Mar 2008, 11:16

edfed

Joined: 20 Feb 2006
Posts: 4354
Location: Now

edfed 26 Mar 2008, 12:14

if you want some already made OO lib, look there

26 Mar 2008, 12:14

itsnobody

Joined: 01 Feb 2008
Posts: 93
Location: Silver Spring, MD

itsnobody 26 Mar 2008, 13:43

daniel.lewis wrote:

forgive me if I'm wrong, but your code would take upwards of 120 cycles to Increment.

It would take ~16 cycles to reload the instruction pipeline through call and then ret. Another cycle for the mov, and 100 cycles because you wrote to memory currently in code cache being executed, which would invoke a cache miss as the code cache block is reloaded with the newly incremented value.

Am I off?

Sounds about right to me...incrementing memory data is a lot slower than incrementing a register, always use registers when you can

26 Mar 2008, 13:43

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20519
Location: In your JS exploiting you and your system

revolution 26 Mar 2008, 14:05

itsnobody wrote:

daniel.lewis wrote:
forgive me if I'm wrong, but your code would take upwards of 120 cycles to Increment.

It would take ~16 cycles to reload the instruction pipeline through call and then ret. Another cycle for the mov, and 100 cycles because you wrote to memory currently in code cache being executed, which would invoke a cache miss as the code cache block is reloaded with the newly incremented value.

Am I off?

Sounds about right to me...incrementing memory data is a lot slower than incrementing a register, always use registers when you can

That is not the reason. Data in the code space is the reason. Basically, unless you want really crappy performance, don't put data and code in the same section.

26 Mar 2008, 14:05

itsnobody

Joined: 01 Feb 2008
Posts: 93
Location: Silver Spring, MD

itsnobody 26 Mar 2008, 14:11

revolution wrote:

itsnobody wrote:

daniel.lewis wrote:
forgive me if I'm wrong, but your code would take upwards of 120 cycles to Increment.

It would take ~16 cycles to reload the instruction pipeline through call and then ret. Another cycle for the mov, and 100 cycles because you wrote to memory currently in code cache being executed, which would invoke a cache miss as the code cache block is reloaded with the newly incremented value.

Am I off?

Sounds about right to me...incrementing memory data is a lot slower than incrementing a register, always use registers when you can
That is not the reason. Data in the code space is the reason. Basically, unless you want really crappy performance, don't put data and code in the same section.

But it's still slow even in different sections, a lot slower than registers, around 4-5 times slower

26 Mar 2008, 14:11

edfed

Joined: 20 Feb 2006
Posts: 4354
Location: Now

edfed 26 Mar 2008, 16:11

finally, i found the name for my OO lib.
FOO, the method, and FOOL the lib.
because f like fasm, OO like OO, and the best:
foo have the same prononciation as [french]FOU[/french], means crazy, mad, ill.
then, it is really a good name for this lib.

then, a demo

i posted still many other codes like it, XHTML.ZIP is based on the same lib, in fact, all my work since 2 years is based on this lib.

thezn, for beginners, i invite you to devellop with it, don't try to devellop your own lib, it's too hard, and soo long that you'l lose all your motivation.

just see the poorness of my examples, it shows how much i'm bored.

the choices are:
devellop lib,
devellop applications.

if you devellop applications first, you'll know what to do in your lib
if you devellop the lib first, you'll be so bored that you'll don't have any energy for application programming.

Wink

Description:	the ORG100H.ASM file is the main entry of the FOO. UFONOSS UF/O2S :D	Download
Filename:	FOOL.zip
Filesize:	30.89 KB
Downloaded:	372 Time(s)

26 Mar 2008, 16:11

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 26 Mar 2008, 17:40

Quote:

then, it is really a good name for this lib

hard work done, now just the make library Laughing

26 Mar 2008, 17:40

hopcode

Joined: 04 Mar 2008
Posts: 563
Location: Germany

hopcode 26 Mar 2008, 18:09

Thanks, vid, for the suggestion to the link. it is an excellent tutorial,
even if incomplete. I hope to read the part about classes inehritance.
This is the first time that i read so well-explained and cleary about the Vtable.
Pardon, if I address you directly, (i am inspired from the quality
of your code and from your availability towards all in tho forum.)

Assembler is important für mich for these reasons:
- energy savings
(because of smaller wasted resources)
- immediacy and contact with the machine.

Perhaps there is something that I cannot preceive, without the hindsight,
due to my little experience of programmer.
Here the zip file mit source code.
...

updated to draft 3
little improvements on pointer allocation
..

_________________
⠓⠕⠏⠉⠕⠙⠑

Last edited by hopcode on 05 Apr 2011, 16:15; edited 2 times in total

26 Mar 2008, 18:09

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 26 Mar 2008, 18:19

Quote:

If I have not misunderstood, the Vtable well is a "list" of pointers to "static" functions. I mean static as "in design preconstructed" and implemented.

yes, it is.

Quote:

Perhaps the Vtable has an other conceptual meaning as well,
that I do not know.

yes, it's needed for inheritance.

I suggest you to study COM programming tutorial in C, somewhere on codeproject. It is very good and covers much more than my small tutorial (even though some parts are COM-specific)

26 Mar 2008, 18:19

edfed

Joined: 20 Feb 2006
Posts: 4354
Location: Now

edfed 26 Mar 2008, 22:23

how can i implement the vtable in fool?
it still have a lot of tables.

a function list for function indexing, and all the code that is constituted by tables.
then, i don't see where to implement the vtable.

some functions can herit the coordinates of the parent item, but it's not always the case.

and it tend to be never the case.
each functions have it's own structure.

for system functions, (or hidden, don't display anything), there is an other structure.
the structure depends on the function itself.

for exemple, the txt function need 2D coordinates colors font, and pointer to text.
then, where is the application of vtable in this case?

26 Mar 2008, 22:23

daniel.lewis

Joined: 28 Jan 2008
Posts: 92

daniel.lewis 27 Mar 2008, 00:30

If you put the methods away from the class, and simply point to them on the class and use jmp [x], or jmp ebx; that should not cause your code to incur the data-write cache flush 100 cycle penalty thinger.

You would want to put all the code for a class together in a block to reduce cache-thrashing between different methods in the class.

Without knowing the internal workings of a vtable:

section .data
[ method*[], void*[] for classes and arrays and char[]'s, bool/int/long/float/double properties struct ]
[subclass]
[string]
[string]

section .text
[method]
[method]

If you were to be able to expand your macro to that, it would qualify for effective Object Oriented programming. To inherit from any object (no classes!) you simply need to allocate the same size as the object, and memcpy() the method*[].

I'm curious if this can be done with asm macros.

_________________
dd 0x90909090 ; problem solved.

27 Mar 2008, 00:30

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 27 Mar 2008, 00:51

edfed: are you sure you understand what a vtable is? aside from syntactically wrong sentences, you seem to be mixing all sort of unreleated stuff together.

27 Mar 2008, 00:51

edfed

Joined: 20 Feb 2006
Posts: 4354
Location: Now

edfed 27 Mar 2008, 00:55

i understand a little.

i see sometimes the need to have a sort of classification. just to be able to pick some common datas from all objects from the same class.
as an exemple, i want to optimise the palette with all colors from all graphical objects.
it's for testing under mode 13h.
but i really don't see how i can implement this trick without an extra tree, with objects classed by family, all with the same header structure...
but how?

27 Mar 2008, 00:55

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 27 Mar 2008, 01:44

i suggest you reading through my article, it could clarify some things

27 Mar 2008, 01:44

edfed

Joined: 20 Feb 2006
Posts: 4354
Location: Now

edfed 27 Mar 2008, 01:58

still read , re read, and re re read, i'll read it one more time then. thanks.

edit:
read and ok, now i see, i still have my vtable, but i called it flist.
and for one object, there is only one method, but there is a meta abject called "node"
this object will contain all subobjects as needed.

for a simple medikit, it will be like that:
medikit dd f.node,x,y,xl,yl,@f-$-4
dd .image,.hit,.asm
@@:
.image dd f.put,0,0,0,0,medibmp,color
. hit dd f.hit,action,@f-$-4
dd target1,target2
@@:
.asm dd f.asm,@f
@@:
mov eax,?
call ?
ret

as you can see, it's not the same way that the original OOP.
all objetc can have any mathod, just create it with a f.asm module.
as you can see, it's a big waste of memory, but it's due to it's use as execution context. each item have it's own execution context for it's method.
need to redesign it..

27 Mar 2008, 01:58

itsnobody

Joined: 01 Feb 2008
Posts: 93
Location: Silver Spring, MD

itsnobody 27 Mar 2008, 03:32

daniel.lewis wrote:

If you put the methods away from the class, and simply point to them on the class and use jmp [x], or jmp ebx; that should not cause your code to incur the data-write cache flush 100 cycle penalty thinger.

You would want to put all the code for a class together in a block to reduce cache-thrashing between different methods in the class.

Without knowing the internal workings of a vtable:

section .data
[ method*[], void*[] for classes and arrays and char[]'s, bool/int/long/float/double properties struct ]
[subclass]
[string]
[string]

section .text
[method]
[method]

If you were to be able to expand your macro to that, it would qualify for effective Object Oriented programming. To inherit from any object (no classes!) you simply need to allocate the same size as the object, and memcpy() the method*[].

I'm curious if this can be done with asm macros.

Wow man you're right

I just did some speed tests, I got 5,000 milliseconds or so with the memory in the data section, and got 255,000 milliseconds with the memory in the same area...thats like 50 times slower, that's a serious performance killer

The fasm local...endl produced the same results as the memory in the data section, so I'm guessing fasm does this automatically some how

Using jmp to another proc also worked effectively the same

This probably can be done with FASM macros, some how

27 Mar 2008, 03:32

edfed

Joined: 20 Feb 2006
Posts: 4354
Location: Now

edfed 27 Mar 2008, 15:57

ok, now i see where it goes wrong.
for exemple, a window, it is composed of many items.
then, instead to declare each item for each window, a window item can be declared.

the inheritance will be for each sub items.
for exemple, the scroll bar, all scroll bars are the same, then no need to redefine the entire composition each time a scroll bar is created.
just create the item scroll bar.

the vtable will not be the same as the func list.
but it will be in the function list.
the node function will call the desired class or function from the flist.

Razz

scrollbar dd scrollbar
dd x,y,xl,yl,colors,data,bounds

in background, it will be equivalent to
Embarassed

scrollbar dd node,x,y,xl,yl,size
dd cursor,throat,butup,butdn,init
etc...

Idea

thanks vid for this guidance. it will simplify a lot the composition.
but before to apply any change to use the classes and vtables, i'll expend the fool and adapt it for pm & vesa.
the simplification will come after a lot of practice of the lib without vtable.
then, i'l see where and how to make the vtable. Shocked

27 Mar 2008, 15:57

daniel.lewis

Joined: 28 Jan 2008
Posts: 92

daniel.lewis 28 Mar 2008, 10:05

Someone let me know if you manage to implement that OO system I mentioned or something similar. I would love to have the macros on hand in case something reasonably fits the OO model.

28 Mar 2008, 10:05

Goto page Previous 1, 2

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum