On Mon, May 20, 2019 at 11:12:04PM -0700, Michael Forney wrote:
> Yes, I tested building gcc-9.1 with gcc-4.7.4 built by my compiler. I
> have not tried gcc-8.
It's very good news (actually less worse news than usual from the gcc world).
> At least gcc tracks the autotools-generated files in the repository,
> so you don't actually need them installed to build.
Indeed, but it still depends on GNU autotools. Anything SDK independant of
perl/python/c++/other kludges baseds SDKs is a good thing: tomorow, you'll have
fanatics of javascript SDKs? typescript SDKs? swift SDKs? python42 SDKs? perl12
SDKs? There is no end to this.
A good trade-of is to re-orthogonalize the build system on several simple and
near linear sh scripts. You choose the most common configurations, and write
such scripts (you would start with one). For "new configurations", since those
would be simple sh scripts, it should be easy to compose new build scripts.
Acutally, the real work does happen in re-writting some code generators.
> The issue is for lower level code that can't be written in C, for
> example making system calls. I don't think inline asm will be too
> difficult to implement in QBE. For the most part I think it can be
> treated similarly to a function call, but with a special calling
> convention.
Hence the "extension keywords" or "function intrinsics". You don't need to
expose, roughly speaking, the "register allocator" through brain f*cked
templates (like gcc inline asm). You keep it internal and it follow the
evolution, if any, of the "register allocator". And no need to keep the
template syntax forever for each assembler... As you said, it would probably
require QBE involvement in some way.
--
Sylvain
Received on Tue May 21 2019 - 18:14:09 CEST