LLL: Fat PIOS

[Raul Deluth Miller]

Raul Miller:
: > I can see a usefulness for including machine executable binaries
: > with PIOS.  However, I can see the usefulness of insisting that
: > such binaries must be accompanied by LLL code -- both for
: > validation work, and for portability.

Mike Prince:
: I don't see how you could validate binary against it's LLL code,
: unless you could generate the binary from the LLL, thus negating the
: need for binary.  Please explain more about validating.

Well,

[1]  In principle, you could run something in test mode, where the LLL
     and the machine specific code are both being fed the same data,
     and the outputs are compared.

[2]  Security concious systems would have to have the option of
     running LLL instead of binary.

[3]  And then there's the case where where you want to migrate the
     program to some system that you don't have binaries for.  [I
     dunno, maybe a CRAY or something...]


: As I said before, we must allow binaries somewhere, lets just keep
: them very close to the kernel and away from everything else.  I see
: binaries;
:   
: On plug in cards in PC's.  Found early enough that the kernel can
: package them up and protect them.

True.

: On drivers for cards in PC's.  A necessary kludge for now, again
: loaded early by the kernel and then packaged up for safety.

True.

: On very specialized hardware.  A box that just provides one tool box
: (a rendering package for instance) that runs very fast.  The tool
: box would come as a fat binary to the kernel that spawned it, but
: look like a normal tool box to everyone else.

Hmm...  You sure you don't want to allow similar specialized platforms
to use the binary?

: My holy war continues...  OK you got me to say FAT BINARIES.  But I
: would like it to be a PER kernel kludge, not a system wide one (or
: is there a difference).

he he he he  yesss... it's all a plot to ...  *ahem*

I don't think we need to make "fat binaries" especially transparent.
Basically, however, they might be thought of as an upgrade mechanism,
to supply fast primitives to older kernels [which don't have such
primitives].

There's no way we can anticipate all future hardware advances, and to
properly take advantage of some of them, we're likely to need some new
primitives (blit, and decrypt come to mind as some instructions that
currently aren't universally supported).  In many cases, the existing
LLL instruction set would be adequate for boot-strapping.  So, adding
the possibility of using PIOS-style code migration for upgrading the
kernel seems like a useful facility.

Which reminds me: most of the current discussion has been about single
coherent processes, aimed at achieving some end.  But there's also the
matter of making commonly needed mechanisms available at many sites.

Raul D. Miller          N=:((*/pq)&|)@              NB. public e, y, n=:*/pq
<rockwell@nova.umd.edu> P=:*N/@:#            NB. */-.,e e.&factors t=:*/<:pq
                        1=t|e*d         NB. pq is two large primes, e medium
x-:d P,:y=:e P,:x                  NB. (d P,:y)-:D P*:^:(i.#D)y [. D=:|.@#.d