[racket-dev] GNU lightning version

At Wed, 03 Sep 2014 13:07:05 +0400, Yaroslav Tsarko wrote:
> are there any 
> reasons why Racket currently uses very old
> version of GNU Lightning? According to sources, Racket 6.1 uses GNU 
> Lightning version 1.2 which originates from 2004
> [...]
> Is it manpower problems (there is nobody who can upgrade this component 
> in Racket), technical ones or something else?

There are a few technical issues, any of which might be addressed by
contributing back to Lighting, but mostly it's a question of manpower.

We've modified GNU Lighting in various ways. Some of those ways turned
out to be uninteresting, and we'd do just as well to re-sync with the
latest Lighting. Other changes involved the conventions for register
and stack usage, where where re-syncing might be more difficult, and
Racket depends on some implementation details instead of treating
Lighting as a black box. Some changes should have been wrappers around
GNU Lighting, in retrospect, so re-syncing would be good, but it's a
lot of work.

I don't know GNU Lightning's current stance on jump distances on
various platforms, but for Racket, we adapted it to handle a mixture of
short jumps (faster when the JIT knows that it will work), long jumps
(otherwise), and very long jumps (on x86-64 when the memory allocated
for code becomes further apart than fit in 32-bit values). Adding the
jump-distance generalizations to 2.0 would take some work, and it's
messy enough that I'm not sure the Lighting maintainers would be happy
to take it.

One other change might be tricky: the x86 build uses both SSE and x87
instructions to support a mixture of flonums and extflonums, and
Lighting originally worked with only one or the other --- but that
might have changed.


> and current version of 
> GNU Lightning is 2.0 which supports many new back-ends, particularly MIPS.

I back-ported ARM support from and almost-2.0 version of Lighting, and
that process was relatively easy. I had to know about and adapt
Racket's assumptions about Lightning, though.