Ease of using Graal to target the Mill

[Mike Hearn]

Apologies if this message is off topic or too speculative for this list.

I recently watched with interest this video:

https://www.youtube.com/watch?v=D7GDTZ45TRw

It is about the efforts being made by a new CPU design startup to port LLVM
to their extremely exotic but general purpose ISA. As a flavour of how
exotic it is, there are no registers, and you can only jump into the start
of an 'extended basic block' (single entry multiple exit). The hardware is
actually oriented around SSA form.

Another key difference is that pointers and integers cannot be trivially
interchanged on their architecture.

There are other differences (flat address space, no syscalls, different
approach to security) that mean they'll probably have to write their own OS
too.

The compiler talk goes into a few differences from normal CPUs but the
entire series of talks is fascinating and if you have an interest in CPU
design I suggest you watch all of them, here:

http://millcomputing.com/docs/

(note: the Mill is not actually being manufactured and is best described
currently as a kind of advanced and detailed vapourware)

Not surprisingly they found that LLVM is difficult to adapt to this kind of
CPU. It got me wondering whether it'd be any easier to use Graal. For
instance by compiling some kind of extended/custom Java that has enough
support for low level/unsafe operations to write an OS in. Specifically my
questions would be:

   1. As Graal is designed to compile safe, GCd languages, I'm assuming it
   tracks the pointerness of variables precisely everywhere and never converts
   pointers to ints or vice versa? Thus they would not encounter the same
   problem they've seen with LLVM, which apparently converts pointers to ints
   during optimisation phases liberally. Is that right?

   2. Given a sufficiently extended form of Java (or any other JVM
   language) and enough hackery, am I correct in thinking that Graal could do
   an AOT compile down into something resembling a kernel image? Is there any
   plan to ever release Substrate as open source?

   3. Oracle built a C frontend for Truffle/Graal at some point. Does that
   support AOT compilation too, or at least persisting the code cache? If so,
   and if there were to be a Mill port, would that be a reasonable way to
   compile C to native code a la gcc/clang?

thanks for indulging my curiousity!