From: groepaz (groepaz_at_gmx.net)
Date: 2002-07-11 20:51:05
Hello Ullrich, UvB> My usual advice for Windows users when strange things start to happen is: UvB> Format the hard disk and do a complete reinstall. This helps in many cases. eh :=P well honest, no ;) there are a dozen compilers running just fine on this machine and i cant really believe it should be windoze by itself that fucks things up. however.... 1) installed cc65 cleanly on another win98 box 2) copied over my c64 dev environment 3) compiled array.c using my dev-environment - DONT work... as before 4) compiled array.c using "cl65 array.c -o array.prg" - THIS WORKS!!! (/me scratching head ;=P) conclusion: bug is indeed located inside my environment, starting to track this down... 5) moving back to the first win98 box, compiling "array.c" using cl65... this ALSO works ... err ;=P 6) compiling by launching utils manually.... cc65 array.c -o array.s ca65 array.s -o array.o ld65 c64.o array.o c64.lib -o array.prg -t c64 ... and the resulting binary does _NOT_ work anymore!!! new conclusion: bug aint related to my dev-environment in particular, but probably to calling tools manually and not through cl65... (i feel much better now ;=P lol) 7) comparing both binaries shows some differences (first is working binary) 00000D98: 44 64 -> should be 'd' 00000D9A: 0D 0A -> should be '\n' 00000D9E: 44 64 00000DA0: 0D 0A 00000DA4: 44 64 00000DA6: 0D 0A 00000DAA: 44 64 00000DAC: 0D 0A the (wrong) data in question is infact constant character-strings quoted in printf's ... investigating further... 8) TADA.... this solves it :o) cc65 array.c -o array.s -t c64 ca65 array.s -o array.o ld65 c64.o array.o c64.lib -o array.prg -t c64 (strange, i _DID_ supply -t c64 to cc65 in my dev-environment before ...eh ;=P) my guess is that infact the added support for different character-translation-tables broke something that worked before (?) ... 9) trying with optimizations.... huhuhu, troubles again ;=P cl65 array.c -o array.prg -O ... and cc65 array.c -o array.s -t c64 -O ca65 array.s -o array.o ld65 c64.o array.o c64.lib -o array.prg -t c64 now BOTH binaries work, but strange enough the second binary is shorter than the first one.... cl65 -S array.c -o array.s -O cc65 array.c -o array.s -t c64 -O ...comparing the generated asm files proves the differences, which are (my guess ;=)) optimizations NOT contained in the binary generated by cl65 ! now it really becomes interisting.... new guess is that cl65 doesnt pass optimization flags correctly (or atleast differently?) as expected.... YES... a quick hack inside cl65 proves it.... it doesnt pass -O flags at ALL !!! PHEW... and the solution is so easy, just never put any switches after filenames .. doh :~] this has probably caused other problems before aswell, argls ;/ 10) pah.... cl65 -o array1.prg -Oirs array.c cc65 -o array2.s -t c64 -Oirs array.c ca65 -o array2.o array2.s ld65 -o array2.prg -t c64 c64.o array2.o c64.lib these do now produce identical, but yet _NON_ working binaries ;=P (/me slowly getting mad ;=D) ok now more hunting.... works: -O -Os -Or -Ors dont work: -Oi -Oirs -Osi -Ori looks like -Oi is fux0red eh? :=P 11) ok, so now this should have really been it.... i changed all my environment to always put filenames last on the command line and i use -Ors now..... looks like this fixes most of the problems i had, cheers :o) however... that unpredictable behaviour related to the order of files and switches on the commandline baffles me ;=P IMHO the order either shouldnt matter at all (preferred ofcoz) OR the respective tool should abort with an error message.... just silently ignoring those switches is BAD BAAAAD style. really UUUUGLY ;=D hehehe (just kidding ;=)) ok, for the -Oi bug its your turn now i guess :o) i am trying to clean up my stuff now and make it work with all your recent changes (that module stuff might actually make the filesystem useful ;=P).... hopefully the testsuite will allow you to find some more subtle problems then aswell :o) (i have found some more notes on problems i had with 2.7.1 ...gotta recheck this stuff aswell :=P) ohwell...this got longer than i thought uh, gotta stop it :P -- Best regards, groepaz mailto:groepaz_at_gmx.net ps: some other little flaws i noticed when tracking this down.... 1) in cl65 cmdline-help is a typo.... it should be "compile and assemble" not "Compiler ..." :=D 2) there should be an easy way to let cl65 print the commandline it uses to call sub-processes. would have saved me some time atleast i guess :o) (i quickly hacked it to do that actually ;=P) ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2002-07-11 20:52:26 CEST