I got the following error when using --oldralloc option: C:\SDCC\BIN\sdcc ne2000.c -mz80 -c --oldralloc --std-c99 --codeseg CODE0 Internal error: validateOpType failed in OP_SYMBOL(IC_RESULT (ic)) @ /home/sdcc- builder/build/sdcc-build/orig/sdcc/src/z80/ralloc.c:863: expected symbol, got va lue ..\bin\make: *** [ne2000.rel] Error 1
Woody http://palmmicro.com/woody/ ----- Original Message ----- From: "Philipp Klaus Krause" <p...@spth.de> To: <sdcc-user@lists.sourceforge.net> Sent: Tuesday, July 12, 2011 6:39 PM Subject: Re: [Sdcc-user] Z80 code size reduction > Am 12.07.2011 07:27, schrieb Lin Rongrong: >> I tried 3.0.4 #6622 (Jul 11 2011) (MINGW32) version today. It took my >> Intel >> Core2 Duo CPU T5800@2GHz with 4GB RAM 34 minutes to build current AR1688 >> 0.53.012 SIP software. The previous 3.0.1 only need less than 2 minutes. > > What's the difference in code size? > I have some dieas about how to get a better compilation speed / code > size trade-off, but I don't want to implement them before the 3.1.0 > release. There's already enough new, potentially buggy stuff in sdcc > that needs more testing as is. > >> Although there is no compile problem now and the code size is indeed >> reduced >> a lot, the compiled result is bad. It can still boot up with DHCP ok, but >> major functions like software upgrade and SIP registration are broken. >> I guess I need to debug with the options mentioned in the following >> email, >> since the compile time is so long right now, I'd like to ask if there is >> any >> option update before I start. >> >> Woody >> >> http://palmmicro.com/woody/ >> >> ----- Original Message ----- >> From: "Philipp Klaus Krause" <p...@spth.de> >> To: "Sdcc-User" <sdcc-user@lists.sourceforge.net> >> Cc: <z88dk-develop...@lists.sourceforge.net> >> Sent: Wednesday, April 06, 2011 11:01 PM >> Subject: [Sdcc-user] Z80 code size reduction >> >> >>> Dear users of the Z80 port, >>> >>> I've been working on a new register allocator for some months. >>> >>> The current protoype already generates better code than current 'normal' >>> sdcc in most cases. A code size reduction of about 10% seems typical. >>> >>> A small benchmark can be found at >>> https://sourceforge.net/apps/trac/sdcc/wiki/Philipp%27s%20TODO%20list, >>> where the rightmost column gives the code sizes for the new allocator. >>> As you can see, with the new allocator sdcc in most cases generates >>> smaller code than all other compilers, including the last HITECH-C >>> compiler. >>> >>> You can download sdcc with the new allocator from >>> http://colecovision.eu/stuff/sdcc-or-2011-4-6.tar.gz. I have worked on >>> fixing bugs for about a week; all regression tests complete without >>> errors, and my own Z80 applications work when compiled with this >>> version. >>> >>> However it's likely that there are still lots of bugs, thus it needs >>> testing. Please test this version of sdcc on your code, and tell me >>> about any problems you encounter. >>> >>> A short description of the command line options you might want to try: >>> >>> --optralloc-exact-cost : Use an exact cost function. This should >>> generate slightly better code than without this option. > > This option has been removed. The exact cost function works so well, > that it is always used in the z80 port now. And since it was never > implemented in the gbz80 port, there's no need for the option there > either. > >>> >>> --max-allocs-per-node : Higher values result in better code, at the cost >>> of longer compile time (and higher memory usage during compilation). The >>> default value is 10000. > > Of course this can be used to speed up compilation, by setting it to a > value lower than 10000 as well. > >>> >>> --opt-code-size : Optimize for code size instead of speed. Currently has >>> a relatively small impact on the code generated. >>> >>> --no-peep : Disables the peephole optimizer. When there's a problem that >>> goes away when using --no-peep it's most likely a bug in the peephole >>> optimizer or the peephole rules. > > I recommend to use this early in testing: Peephole rule bugs seem > relatively common and tend to be easy to track down and fix. > > There's --oldralloc now as well, which uses the old register allocator. > This is probably useful to track problems down to a single source file. > > Philipp > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Sdcc-user mailing list > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
