"parse error before numeric constant"

Discuss the development of software, tools, libraries and anything else that helps make ps2dev happen.

Moderators: cheriff, Herben

Post Reply
User avatar
Saotome
Posts: 182
Joined: Sat Apr 03, 2004 3:45 am

"parse error before numeric constant"

Post by 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:

Code: Select all

		ori			$20,$0,1
		pcpyld		$20,$20,$20
		pcpyh		$20,$20 /* set all halfwords to "1" */
		pand		$20,$20,$14 /* only first 3 hwords of a dword */
after lots of tries and errors i took out the quotes form the "1" and it worked :D

now is that a bug or is it there on purpose? o_O
can anyone tell me?
thanks
infj
User avatar
Drakonite
Site Admin
Posts: 990
Joined: Sat Jan 17, 2004 1:30 am
Contact:

Post by 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
User avatar
Saotome
Posts: 182
Joined: Sat Apr 03, 2004 3:45 am

Post by 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:

Code: Select all

 /* lq $8,0x0(%2) */
i get the error message "operand number out of range", when there is only %0 and %1 as parameter for example.
not that it really bothers me but i just wondered ;P
infj
dlanor
Posts: 258
Joined: Thu Oct 28, 2004 6:28 pm
Location: Stockholm, Sweden

Post by 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
Posts: 791
Joined: Fri Jan 30, 2004 11:43 pm

Post by 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.
User avatar
Drakonite
Site Admin
Posts: 990
Joined: Sat Jan 17, 2004 1:30 am
Contact:

Post by Drakonite »

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