9 replies to this topic

[Mihail121]

Ok so here is the deal:

I wanted to write my newly written raycaster in ASM. To understand whether there is some point in doing that i decided to make this experiment: go to the biggest res supported, create a dib section and fill it every frame with random pixels. I first do it for 10 seconds with C routine and then with assembler one. It's simply a profiler compare after that ;)

and now the real problem:

Iuse MASM to write the ASM routine. Since i need the rand() func for the random pixels i define it's proto in the ASM file:

rand PROTO c

and then simply use it. Upon link with GCC (which links with stdlib) the correct address for the rand function is found and used. __BUT__ - when i call the rand from the C routine everything is fine, when i call it from the ASM routine the app CRASHES?!.

Yes, yes i'm 100% sure that i use the correct calling convention and all addresses are computed correctly. Also i bet five bucks the damn stack frame for the call is correct cause the rand function simply doesn't have any parameters :D

Does anyone have any ideas on this one?

P.S.

A little hint, the function abs() from the same lib (stdlib that is) is called from the ASM routine correctly.

[LuciferX]

Ahhhh.. fond memories of MASM.

Unfortunatly, in answer to your question, not that Many memories ;)

[Nick]

Why use MASM? In Visual C++, you can simply use the __asm keyword for assembly blocks. So you can simply write assembly code between your C++ code, where it matters. You can even use the C++ variables directly, the compiler will figure out their real location in memory.

[Mihail121]

Cause i'm not using VC++, that's why :) I'm using mainly the GCC system and their assembler is hell to read and write, therefore MASM.

Of course, a lot of stuff changed since them and i'm not doing it with FreePascal, which is highly customizable (you can even choose your favorite ASM syntax).

[Nick]

Mihail121 said:

Cause i'm not using VC++, that's why :)

And why is that? :wink: I highly recommend Visual Studio .NET 2003. The 2005 beta is even for free. I haven't tried it yet though.

[Mihail121]

Nick said:

Mihail121 said:

Cause i'm not using VC++, that's why :)

And why is that? :wink: I highly recommend Visual Studio .NET 2003. The 2005 beta is even for free. I haven't tried it yet though.

Ok let's not start a flame war :blush: i just don't like, it that's all. I'm feeling a lot more comfortable with GCC, FP, Java SE and NASM and Notepad 2 :).

[Michael]

Notepad2 is great, I had almost replace good old vim by it :)

[anubis]

what is so ugly about the gcc inline assembler ? you have to put the asm code into " ". that's all...

[Nick]

Mihail121 said:

Ok let's not start a flame war :blush: i just don't like, it that's all. I'm feeling a lot more comfortable with GCC, FP, Java SE and NASM and Notepad 2 :).

Suit yourself. You asked for a way to do this the easy way... :tongue:

Seriously now, couldn't you just use a debugger, and step through the code in assembly to see what it does and where things go wrong? That would be really easy in Visual Stu... hehe. :blush:

[Nick]

anubis said:

what is so ugly about the gcc inline assembler ? you have to put the asm code into " ". that's all...

Not just that. As far as I know, it only supports AT&T syntax, which dates from before text parsing technology. Every register has to be prepended with '%', every constant with '$'. Instruction mnemonics need a 'b', 'w' or 'l' at the end to indicate the size of the operands (it doesn't automatically determine this from the registers used). It also has an ugly confusing syntax for referencing memory, and to top it off the destination operand is put last...

Clearly the Intel syntax is superiour. Here the compiler (or should I say assembler) does a lot of work for you. You don't have to 'help it out' with the prepended symbols. It can determine the operand sizes itself, and referencing memory has a clear but flexible syntax.

Why GCC got stuck with AT&T syntax I don't know. It was invented to be able to write a really small parser (read: lazy compiler programmer). But that obvioulsy has no advantage any more today. :dry: