lightning
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Lightning] Register allocation semantics


From: Ian Grant
Subject: [Lightning] Register allocation semantics
Date: Wed, 3 Sep 2014 01:05:51 -0400

There is nothing in the manual that either suggests register allocation is necessary, nor that it is something that lightning does.

The idea that by restricting to six GP registers and six (or seven?) FP registers gives a straightforward, well-defined semantics for all processors seems on the face of it a good one.

The recent post suggests that the semantics is in fact not so well-defined.

If the register allocation algorithm has any observable effects above the API then those need to be clearly defined because the utility of a library depends completely upon the interface being intelligible from the documentation, and lightning's is most certainly not. Unfortunately the code is such that it is not intelligible through reading that either.

This is not good. We need to make the core functionality of the tool very much more clear than it currently is.

We also need to get it to the point where it doesn't crash the user's process. This code is sub-alpha quality, and it should not have been released.

What it needs is a complete ground-up rewrite. The result will be a maintainable program which is about 10% of the size of the current release and works about ten times better.

Before we do this we need to clearly specify a guaranteed core semantics, and then we can extend this by sub-setting on the supported (fragments of) CPU architectures. So we allow the user to specify a class of support and then error when they exceed that support. They can then decide whether to further restrict the support they require, or work around that missing feature at the level of support they need.

None of this is rocket science. All lightning is, is a program that constructs strings of bytes. There is no reason whatsoever that such a program should ever crash. So we need to make sure that it never ever crashes while compiling, whatever crazy sequence of calls the user makes.

Sorry if this sounds harsh criticism, but I consider that I have earned the right through the hundred or so hours I've spent trying to find the cause of crashes in my code, which invariably turn out to be deficiencies in lightning and/or its documentation.  Developer's time is too scarce and precious to be wasted like this.

Ian


reply via email to

[Prev in Thread] Current Thread [Next in Thread]