On Thu, 16 Apr 2015 09:35:34 +0200
MFLD <mfld.fr@xxxxxxxxx> wrote:
> Hello,
>
> Thanks for the interesting info about various toolchains for Fuzix. I
> wonder why you include x86_16 target in the Fuzix challenge, as ELKS is
> already playing on that ground, but that is your baby, so...
I built the core that way mostly to check it compiled. Just portability
testing.
>
> Back to ELKS : from what I see in the Coherent tree ('duff' was my
> friend to have a more clear view), CC and AS386 output object files in
> COFF, not A.OUT as BCC and AS86, so we would have to migrate to the
as386 outputs coff for 386 code. The 286/8086 ones appear to produce
*.out (a.out/l.ou/x.out) type formats.
> splitting the recursive parser / code generator in BCC to keep it
> simple, easy understandable and more maintainable (BCC = Basic C
> Compiler for Beginner ?), following the PCC design without portability
Bruce's C compiler after the man who wrote it, initially for 6809 and
later for 8086.
> in mind, and to be able to improve the register allocator without
> dealing with any generic register representation as in GCC.
That and an ANSI parser would make a huge difference I agree.
> The latest because I see Juan or Jody saving few bytes with big effort,
> while many bytes could be saved at the root by optimizing register usage
> in function bodies (starting with the SI / DI push / pop for nothing);
> and because I am already breaking the 64K segment limit with a first
> draft of an Ethernet driver for my board. ANSI non-compliance is not
> really a concern at that stage. But I could understand my rational is
> only valid for my specific use case...
ANSI is valuable for debug.
For size I'd also look at things like wait queues and any repetetive long
winded pieces of code (eg Linux style wait queues). There certainly was
plenty of stuff in ELKS that was taken from 386 Linux and is perhaps
somewhat over-engineered for the job (buffer cache is perhaps one bit
still)
Going to multiple-segments for code isn't too difficult providing you
don't follow every detail of pointers to function, but just stick to
arrays of function pointers or function pointers within segment, but
always seems to me like admitting defeat 8)
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
