Re: porting efforts

[Gabriel Wicki]

Hey janneke and Ekaitz!


Thanks for the prompt replies!  Yes, i've used (and successfully built)
MES on our bootstrapped M2-Planet/M1/hex2 stack (yay!).  I have also
seen wlaan's work - unfortunately the underlying M1/hex2 stack changed
quite significantly which rendered their work kind of useless but
improved provability/understandability a bunch.



On the i386:negate and i386:zf->r being identical issue: I'd delete the
body of one of the procedures and call the other one.  Then it's clear
that what they do is identical (no need to read twice), the names stay
(for now) and if something needed to be changed there's a single point
to change.


> Ouch, no flags that could become interesting.  Have you looked at how
> Stage 0 (M2-Planet) does this?
This shouldn't be a problem (though it kind of interferes with how MEScc
is designed): in RISC-V comparison (and conditional branches) are taken
care of by two families of instructions.  SLT (set if less than) which
can also be used for "set if equal to zero", "set if not equal to zero"
and of course "set if greater than" (with reversed register arguments)
and the conditional branch instructions: BEQ (branch if equal), BNE
(branch if not equal), BGE, BLT, BGEZ, BNEZ, etc.

So, coming from a RISC-V perspective (without much experience in any
other ISA) MEScc feels to be really built around an x86 mindset.  Maybe
it would improve readability/understandability of MEScc if we could map
NYACC's output a bit more directly to architecture-specific
instructions?  Or maybe we can add a layer of abstraction where
conditionals are generated depending on the architecture making use of
flags or not?

Maybe something like this:
(pmatch o
  ...
  ((ne ,a ,b)
    (if (flaggy-arch? info)
        (flaggy-ne info)  ;; which calls test-r, xor-zf and zf->r
        (set-if-ne info))) ;; which sets our designated register
  ...
  )


I will still have to reserve a register for a "comparison" flag, but
instead of translating from x86 in a (probably wasteful/unreadable) 1:1
fashion we could make use of RISC-V's aesthetically pleasing design.

Without such an adaption i would have to think of a way to actually
literally translate the three instructions in question -- without
breaking what each of the instructions does in a different context.  I
sense that to be hard to impossible to achieve and doubt it will ease
verifiability.


@ekaitz: Do you really think it's important to address tiny RISC-V
architectures right now?  There's no 32bit Linux-compatible hardware
(yet) and i'm not sure if there will ever be an even tinier architecture
running MES.  But of course i can simply choose x15 as "status"
register.



Thanks again

gabriel