From: MFLD <mfld.fr@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: ELKS <Linux-8086@Vger.Kernel.Org>
Subject: Re: We have a whole new ton of goodies to investigate...
Date: Thu, 16 Apr 2015 09:35:34 +0200 [thread overview]
Message-ID: <552F6646.9060703@gmail.com> (raw)
In-Reply-To: <20150415224107.69e71308@www.etchedpixels.co.uk>
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...
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
associated LD386, and update other tools as DIS88 (and the upcoming
MON86 and EMU86, scoop!). And despite that move, staying out of the
mainsteam on an unmaintained toolchain...
I am afraid it would be a too heavy workload just to have fun with old
hardware or for learning purpose. I would instead spend my spare time in
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
in mind, and to be able to improve the register allocator without
dealing with any generic register representation as in GCC.
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...
Regards,
MFLD
Le 15/04/2015 23:41, Alan Cox a écrit :
> Started to have a look to that huge stuff (not really sorted...), but
> could you please explain the idea you have in mind ? Is this a suggest
> to replace the DEV86 toolchain by something else ?
> >At least the compiler. The Coherent compiler is an ANSI C compiler with a
> reasonably good optimiser on it. The tree seems to have versions for
> 8086, 80286 (protected mode included) and 80386 (which is probably not
> useful)
>
> >8086 I did a test build of the core with bcc, but would probably use
> the coherent compiler eventually if it did 8086. Not sure there is
> that much point doing 8086, fixing the dumber bits ELKS inherited from
> 32bit Linux would probably shrink it down to the point the size change
> wasn't that big a deal. Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-04-16 7:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-03 20:40 We have a whole new ton of goodies to investigate Alan Cox
2015-04-15 17:10 ` MFLD
2015-04-15 21:41 ` Alan Cox
2015-04-16 7:35 ` MFLD [this message]
2015-04-16 11:49 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2015-04-16 11:14 LM
2015-04-16 11:39 ` Alan Cox
2015-04-26 21:22 u-vpoa
2015-04-26 23:31 ` Alan Cox
2015-04-27 7:06 ` u-vpoa
2015-04-27 10:53 ` Alan Cox
2015-04-27 12:30 ` u-vpoa
2015-04-27 13:35 ` Alan Cox
2015-04-27 14:44 ` u-vpoa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=552F6646.9060703@gmail.com \
--to=mfld.fr@gmail.com \
--cc=Linux-8086@Vger.Kernel.Org \
--cc=alan@lxorguk.ukuu.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox