cro.com/woody/
- Original Message -
From: "Philipp Klaus Krause"
To:
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 to
Am 14.07.2011 19:41, schrieb Lin Rongrong:
> I tried #6623 with a simpler code configuration, which uses IAX2 protocol
> instead of SIP. And found the "jp to jr" problem back again:
It's not back. It rather looks like it was never really fixed for jumps
in jump-tables (which are handled different
08$
;menu.c:1144: case SETTINGS_MENU_VOICE:
00104$:
Woody
http://palmmicro.com/woody/
- Original Message -
From: "Lin Rongrong"
To: ;
Sent: Friday, July 15, 2011 12:42 AM
Subject: Re: [Sdcc-user] Z80 code size reduction
> Just tested #6623 with "--max-allocs-per-node 4
uly 14, 2011 4:08 AM
Subject: Re: [Sdcc-user] Z80 code size reduction
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am 13.07.2011 04:24, schrieb Lin Rongrong:
>> --max-allocs-per-node 100 reduced compile time to 5 minutes. But it
>> generated larger code size than 3.0.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 12.07.2011 14:57, schrieb Lin Rongrong:
> 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)) @
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 13.07.2011 04:24, schrieb Lin Rongrong:
> --max-allocs-per-node 100 reduced compile time to 5 minutes. But it
> generated larger code size than 3.0.1, caused a bank overflow in my case and
> thus can not generate a binary file to test whether the
nesday, July 13, 2011 10:48 AM
Subject: Re: [Sdcc-user] Z80 code size reduction
> --max-allocs-per-node 300 took 6 minutes to compile, caused a bank
> overflow and can not generate a binary file to test.
>
> Woody
>
> http://palmmicro.com/woody/
>
> - Original
file to test whether the result is
>> correct or wrong.
>>
>> Woody
>>
>> http://palmmicro.com/woody/
>>
>> ----- Original Message -
>> From: "Lin Rongrong"
>> To: ;
>> Sent: Wednesday, July 13, 2011 10:09 AM
>> Subje
--max-allocs-per-node 500 took 7 minutes to compile, and generated another
different run time error pattern.
Woody
http://palmmicro.com/woody/
- Original Message -
From: "Lin Rongrong"
To: ;
Sent: Wednesday, July 13, 2011 10:24 AM
Subject: Re: [Sdcc-user] Z80 code size
-
From: "Lin Rongrong"
To: ;
Sent: Wednesday, July 13, 2011 10:09 AM
Subject: Re: [Sdcc-user] Z80 code size reduction
> --max-allocs-per-node 1000 reduced compile time from 34 minutes to 9
> minutes. The result is still wrong, but in a different pattern now.
>
> Woody
&g
Re: [Sdcc-user] Z80 code size reduction
> Am 12.07.2011 15:38, schrieb Lin Rongrong:
>> After another half hour compile with --no-peep option, I sadly found the
>> same problem. Seems that the peephole optimizer is not the source of
>> error.
>>
>> Woody
>&
Am 12.07.2011 15:38, schrieb Lin Rongrong:
> After another half hour compile with --no-peep option, I sadly found the
> same problem. Seems that the peephole optimizer is not the source of error.
>
> Woody
>
While I have no idea what kind of program results in such long compile
times using the
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 s
..\bin\make: *** [ne2000.rel] Error 1
Woody
http://palmmicro.com/woody/
- Original Message -
From: "Philipp Klaus Krause"
To:
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:
>>
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
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.
Although there is no compile problem now and the code size is indeed reduc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 11.04.2011 16:51, schrieb Harley Laue:
>> --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 1.
>
> I was a bit surprised how
On Sun, Apr 10, 2011 at 4:36 AM, Philipp Klaus Krause wrote:
> Am 08.04.2011 16:54, schrieb Harley Laue:
>
>> I think I may have found one. I'll attach the code. It appears it
>> doesn't like one of my macros. It works in sdcc (I don't have it in
>> there, but you can add --opt-code-size and any o
Am 08.04.2011 16:54, schrieb Harley Laue:
> I think I may have found one. I'll attach the code. It appears it
> doesn't like one of my macros. It works in sdcc (I don't have it in
> there, but you can add --opt-code-size and any other options you'd
> like to the CC line in src/Makefile) Just FYI,
Philipp Klaus Krause wrote:
> Another update, with another bug fixed at:
>
> http://colecovision.eu/stuff/sdcc-or-2011-4-8.tar.gz
>
> I have now run out of bugs to fix. This doesn't mean there aren't any
> left, but rather that I need your help to find them.
>
> Philipp
I think I may have found on
Another update, with another bug fixed at:
http://colecovision.eu/stuff/sdcc-or-2011-4-8.tar.gz
I have now run out of bugs to fix. This doesn't mean there aren't any
left, but rather that I need your help to find them.
Philipp
Am 06.04.2011 17:01, schrieb Philipp Klaus Krause:
> You can download sdcc with the new allocator from
> http://colecovision.eu/stuff/sdcc-or-2011-4-6.tar.gz.
Today's version, with some bugs fixed can be found at:
http://colecovision.eu/stuff/sdcc-or-2011-4-7.tar.gz
Philipp
---
On Wed, Apr 6, 2011 at 10:01 AM, Philipp Klaus Krause wrote:
> 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
23 matches
Mail list logo
