> When I have the tie and memory, I sometimes go up to
> --max-allocs-per-node 10000000. However, long and long long have not
> been the focus of optimization. So far they seemed relatively rare. And
> optimizations tend to focus on the common case.
I gave it a spin at 1000000 max allocs per node and it took about two
hours to build. It did come out another 2.5K shorter which is pretty
impressive (down from 34K to 31.5K). Might even fit into 2 16K ROM banks
like that, assuming I can find an efficient split.
Not tried booting it yet though ;-)
The resulting asm for long types seems to be a fair bit better but it's
still making a couple of repeated bizarre choices. In particular
_sd_init_start::
_sd_init:
;devsd.c:134: sd_first_uzi_sector = 0;
xor a, a
ld (#_sd_first_uzi_sector + 0),a
ld (#_sd_first_uzi_sector + 1),a
ld (#_sd_first_uzi_sector + 2),a
ld (#_sd_first_uzi_sector + 3),a
;devsd.c:135: sd_blockdev_count = 0;
ld hl,#_sd_blockdev_count + 0
ld (hl), #0x00
ld hl,#_sd_blockdev_count + 1
ld (hl), #0x00
is still there (not using inc hl or the fact a is known to be 0
much of the rest of the code size looks now to be limited just by the lack
of call with arguments in registers
> > It's also noticable the compiler seems to like to generate weirdness like
> >
> > pop af
> > ld hl, something
> > push hl
> > [reloads hl with something different before reuse]
> >
> > not the expected
> >
> > ld hl, something
> > ex (sp), hl
>
> Can You give a short compileable example to reproduce this?
I will try - it's the usual story, the obvious test case works fine 8)
Alan
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
