> * Faster register allocator reduces compilation time by about 25% (does
> not apply to mcs51, ds390 which use a different register allocator).
Noticably so for the most part, although the V7 dc code in Fuzix seems to
have gone the other way and now takes my machine over 10 minutes and 16GB
of memory to build !
With one exception everything built (see below) although I need to do
more run testing and see what other than the kernel broke and why.
> * New methods to obtain tree-decompositions of control-flow graphs
> improve compilation time / code-quality trade-off (when SDCC is built
> with support for the treedec library).
Where do I find the treedec library ?
Without the treedec library the code generated seems to be slightly
larger although some grew, some shrunk and it's not by much. More of a
concern is that the resulting kernel image doesn't boot with 3.7.0rc1,
but I need to do some digging to see why.
I also have some parts of my build producing the message
../../Library/tools/fcc -O2 -c uud.c
used unbound variable in replacement
which looks like some kind of escaped debugging ??
While the MWC originated ed command causes the compiler to crash
Caught signal 11: SIGSEGV
make[2]: *** [Makefile.z80:49: ed.rel] Error 1
which I need to look at getting some kind of debug for you.
The mixed 16/32bit maths doesn't appear to have helped much in my Fuzix
kernel cases. It still tends to try and load stuff into registers it
doesn't need to (trivial example below). These btw aren't complaints -
I'm just highlighting cases I've noticed that may be worth the compiler
learning about.
Function uoff
; ---------------------------------
; Register assignment might be sub-optimal.
; Stack space usage: 0 bytes.
_uoff:
;inode.c:32: return BLKOFF((uint16_t)udata.u_offset);
; genPointerGet
ld hl, (#(_udata + 0x0064) + 0)
ld bc, (#(_udata + 0x0064) + 2)
; genCast
;fetchPairLong
; genAnd
ld a, h
and a, #0x01
ld h, a
; genRet
;fetchPairLong
; genLabel
; peephole 158 removed unused label 00101$.
;inode.c:33: }
; genEndFunction
ret
It also still doesn't figure out big constant shifts on longs. For
example a static ulong being >> 9 generates a loads into four registers
and a set of 9 loops of 4 shifts. GCC on 6809 instead generates 3 bytes
of loads one set of shifts and a zero of the top byte.
It's even more painful with big shifts. SDCC turns
if (staticlongval >> 25)
into a ton of loads and shifts
gcc generates the 6809 equivalent of
ld a,(hibyteoflong)
and #0xFE
and SDCC still seems to try and generate 32bit loads when told to do
((uint16_t)x) and use that for an operation.
Alan
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
