forums.ps2dev.org

[Saotome]

i just noticed something, what might be a bug in the toolchain.
i was already wondering several times, why the compiler gives me error-messages because of syntax-errors in assembler lines which i commented out anyway (with /* ... */ ).

now i had a very tricky one, since the error message was
"parse error before numeric constant" and no info in which line it really was (actually line 20 where the "asm __volatile__" was, not really helpfull, since there was 200 lines asm-code).

the lines where i finally found it were:

[Drakonite]

Is this inline assembly?
Then I'd assume the " is pairing up with the " at the beginning of the inline assembly.

Since it's part of a string literal, the C processor doesn't see the /* */'s as comments;they are passed on to the assembly and are later seen as comments by the assembler.

Or something of that nature, tv is calling..
_________________
Shoot Pixels Not People!
Makeshift Development

[Saotome]

ah sure, you are right, now i feel a bit stupid
thanks ;)

anyway theres another issue with comments,
if i write something like this in my inline assembly code:

[dlanor]

My reply may be a bit off-topic, but since the main issue has already been solved that shouldn't matter. :)

This topic reminded me of another problem I have with inline assembly, which forces me to edit nearly all sample/demo sources that use them, before I can compile them successfully.

Apparently most (or at least many) of the PS2Dev coders still use the old compilers that allowed multiline strings, since all those sources use them. With version 3.2.2, however, which I use (found at this site) that is forbidden, and all such strings must be broken down into substrings.

I really think it would be a good idea for everyone, including those who continue using old compilers, to adopt that practice. This way the sources will work fine with both old and new compilers, which is surely what we all want.

Best regards: dlanor

[pixel]

I also have to say that many coders are using "bad inline asm practice" :)

For example, one should use register aliases, and if not applicable, tell gcc which registers was pruned.

I've seen too much inlined asm assuming that $a0 was containing the first argument of the function, when the inlined asm was placed ontop of the C function. Well, fondamentaly, this is right. But when using gcc's inline capabilities, one should really use the right way to place the arguments (out/in/clob) to the inline asm bloc.

Typing "gcc inline asm" in google already gives lots of pages. Okay, they are mostly for x86, but this does apply for mips as well.

And remember gcc always put your inline asm code inside .set reorder tags, so that you don't have to swap opcodes, nor add any superfluous nop, such as after a load or something.
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

[Drakonite]

dlanor: The problem is more that there is a lot of old code that needs updating.
_________________
Shoot Pixels Not People!
Makeshift Development