From: <pa...@pj...> - 2001-05-24 16:39:03
|
I ran into another inline asm bug. Here is some code that reproduces the problem: http://www.pjrc.com/tmp/printf.c There are two _asm _endasm blocks. When I added the first block, which is quite small, it causes the second large block to be truncated. The large block is cut off in the middle of a line, which causes asx8051 to choke. I put the exact lines numbers where this occurs in the C and asm output in a comment in the code. I have a quick asx8051 question. I wanted to include lines like: cjne a, #'d', some_label but asx8051 doesn't accept that syntax. If I change the 'd' to "d", it will build the output, but the immediate addressing moves 0x22 (the quote character). The d and second quote are silently ignored. I think asx8051 is handling this as a 16 bit constant and silently discarding the upper 8 bits, where the 0x22 included in the output is actually the second quote. This was quite confusing for a while. According to the manual (line 796 in as/doc/asmlnk.doc) the correct syntax is supposed to be something like: cjne a, #'d, some_label yes, without a closing single quote, funny as that seems. When I tried this I get an "unterminated character constant" error, which appears to be from sdcc and not asx8051. Is there a way to use character constants within inline assembly code in sdcc? I tried many other syntatical guesses and all ended up as errors or incorrect output code. The documented opening-but-no-closing single quote syntax is so strange from a C perspective that I think it would be best if sdcc could translate 'd' into 'd when it copies the inline asm. I tried the one-quote syntax with this little test code: label: cjne a, #'d, label using "asx8051 -slop test.asm" to build it, and indeed asx8051 produces correct output for it: 0000 1 label: 0000 B4 64 FD 2 cjne a, #'d, label There just doesn't seem to be a way to do this when the asm code is inline and passed through sdcc. Paul |
From: Johan K. <joh...@id...> - 2001-05-24 21:49:52
|
> /* Sdcc also prints annoying warnings that "fmt" is unreferenced, > * which is technically true from a C-syntax point of view. That > * warning should probably be suppressed when the function > * contains an inline assembly block that can reference variables > */ No, if you are doing inline asm things, you're on your own. Sdcc protects you from the C point of view. If, and only IF, you know what you are doing, you can fool the compiler with a dummy statement "fmt;" like in sdcc/device/lib/ds390/memcpyx.c I will look at the inline asm woes in the morning. That's past 10.30 GMT+1, because that's my day off. Johan P.S. In my opinion, sdcc should throw a warning for that, something like "statement with no effect". But since gcc doesn't, it's probably not ANSI ;) |
From: Johan K. <joh...@id...> - 2001-05-25 08:44:09
|
> I will look at the inline asm woes in the morning. That's past 10.30 GMT+1, > because that's my day off. Fixed. realloc() not only re-allocates, but also re-locates some times. Johan |