Re: Where to host ChezScheme boot images

[Aleksej Lebedev <root%zta.lk@localhost>]

On 2017-05-16 17:22, Robert Elz wrote:
> Date:        Tue, 16 May 2017 15:47:26 +0200
>     From:        Aleksej Lebedev <root%zta.lk@localhost>
>     Message-ID:  <82b9437b1f923ebdfe46f698e554b751%zta.lk@localhost>
>
>
>   | And it is very portable: the boot image for a new platform can be
>   | cross-compiled.
>   | That's what I'm about to do: compile boot image for BSDs on Linux 
> (or
>   | Mac OS, doesn't matter).
>
> First, what does a boot image for BSD really mean, which system 
> architecture,
> or does that not matter?

It does matter. Currently, ChezScheme officially supports only i386 & 
amd64
archs and Linux, MacOS X & Windows.

But it used to support three BSDs (Net-, Open- & Free-), so these can be 
simply
re-enabled and boot images can be generated. I tried FreeBSD, it works.
Although, there will probably be failing tests.

In addition to that, there is still definitions for the ppc32 left in 
the
code. I didn't try to enable it, but it should be possible and easy, 
considering
that the code is very readable. So the support for, say, NetBSD ppc32, 
can
probably introduced without writing any code (just by fixing configs and
Makefiles).

As for the other architectures, real work must be done,
although it should not be very hard either. ChezScheme uses its own 
framework
for defining architectures. Anyway, this is in theory, I didn't really 
dig that
deep.

> But to claim that you run on NetBSD you really need to support i386,
> adm64, sparc64 (and sparc 32 bit) ARM (incl 64 bit), and MIPS at a very
> minimum, support for Motorola 68K based systems, VAX, PowerPC and more
> would be nice as well.    Just supporting one (or two) of those isn't
> really very good.

As I described, only i386, amd64 and maybe ppc32, can be supported
without writing any code. Everything else requires some work.

> The standard solution to this problem is to port your system to a new
> (very simple) architecture that you can define yourself (or you can 
> pick
> one that already exists).   You make your compiler generate code for 
> that
> architecture.   Then you write a (usually quite simple) interpreter for
> that architecture in some programming language that is widely 
> supported.
> When I first saw this done, that was fortran...  (the original, not
> one of the modern vamped up things.)   These days, probably C (or perl,
> or python, or java, or ...)

Well, ChezScheme almost follows this pattern, except in
"write ... in some programming language that is widely supported" part 
:-).

But in my opinion this is very well compensated by the fact that
boot images can be cross-compiled, provided that the definition for the 
new
architecture is written in their own (quite readable) DSL.

> Then that interpreter interprets your compiler (most probably very 
> slowly)
> and you feed that slow compiler its own source code to compile, and
> generate executables for the system you really want to run on (doing 
> that
> part of the compiler porting to a new architecture/system is the hard
> part, but that is the same whatever mechanism you use to compile this
> code, cross compiling, or via the simple bootstrap architecture.)
>
> Even if after you have done that you have to compile it one more time,
> if the version that runs on the virtual machine is cut down too much,
> or just too slow, to compile everything that you really want compiled
> that's OK, you can go through as mant steps of gradually bigger 
> compilers
> compiling even bigger ones until you are done.
>
> But this way no-one ever needs to trust some binary blob that they
> cannot read in order to get started.

Yep. I agree 99%. 1% is for this "some programming language that is 
widely
supported". Compiler for this widely supported language is still a blob.
Or it must be bootstrapped too... But I'm getting too philosophical :-).

There is quite an interesting alternative approach chosen by
Scheme48 developers. In order to bootstrap Scheme, they use so-called
PreScheme (non-GC, non-typesafe subset of Scheme) for which they wrote
a Scheme to C translator. In this PreScheme they wrote their virtual 
machine.
The PreScheme compiler is written in Scheme too, but since it can be
compiled on any platform (technically translated to C on other platform, 
and
then compiled to machine code on the one where it needs to be 
bootstrapped),
there is no problem.

From the pkgsrc's point of view, Scheme48 is bootstrapped from C, 
because
they simple include auto-generated C code the virtual machine in the 
distributed
tarball, but in reality it's completely written in Scheme.
This is kind of cool.


> kre

--
Aleksej Lebedev