Re: porting efforts

[Jan Nieuwenhuizen]

Gabriel Wicki writes:

Hi!

> Small update from my part: i got MEScc to compile RISC-V code -- but
> it's not ready yet.

That's great news, well done!

> 1. I think MEScc needs more documentation, most of all on internal
> workings and design decisions.  AFAICT there's the one info page on how
> to invoke MEScc (which is fine) but since the goal of bootstrapping is
> verifiability, all code should be verifiable -- for which intentions
> should be clear.
> Not sure whether we share that feeling, but imho the more verbose the
> better.

The documentation is lacking/lagging behind; I totally agree.

> My suggestions (and i'd happily work towards that goal): extend the
> README.md and add inline comments to the code for clarification.

That would be nice.  Note that we will want to have all relevant
documentation in the texinfo manual.  And yes, comments in the code
would be very helpful.  It would be great if the next person reading
the code has an easier job than you had ;)

> I also think a less confusing way of naming procedures might be an
> advantage to a verifier: "r0-r1" means difference, whereas in
> "r0-or-r1" the dash is simply a separator; i'm still not 100% sure what
> "r0->r1-mem*n-" is supposed to mean... ;)

I agree.  A predictable naming scheme would be good. "r0-r1 should have
been named "r0---r" at least, but r0-sub-r1 is probably better?

> 2. In the process of understanding MEScc i noticed that MEScc seems not
> to be too clearly split from x86 architecture specifics:
>   module/mescc/armv4/as.scm
> mentions "Note: Pretends to be on x86 a lot" twice, x86 specific
> instructions are emitted from the compile-module (swap-r0-r1, r*n), the
> first register in arch:registers (eax) is treated in a special way, etc.

Yes...

> Although this probably could be worked around in other architectures,
> i'm not sure whether this really fits MEScc's intentions.
> Does a verifier who knows ARM or RISC-V really need to learn the
> aesthetically-not-so-pleasing details of x86 implementation?

I am very happy to see that Mes has grown past the "See it's possible
and it works" phase.  Transparency is an important and worthwile (next)
goal.

> For my current WIP[0] i added a "riscy-arch?" flag to compile.scm which
> arbitrates what assembler procedures should be compiled, but this doesn't
> feel too right -- especially if RISC-V is the only arch to do so.

Your hack/initial solution with the flag makes sense.  Just as I think
it made sense to have the ARM backend go through some loops to mimic
x86.  Both backends did the least that could possibly work, and were
probably written without a full understanding of what to do initially.
Come to think of it, the same excuse would proabably hold for the
initial x86 backend.

> I'd suggest transparently matching from NYACC's AST to MEScc's as.scm
> procedures, keeping MEScc's code clean and move gory specifics (like r*n)
> as far out (to arch-specific as.scm) as possible.

> What do you think?

I think that being needlessly generic/abstract can be just as bad as
being too specific.  It's apparent that MesCC's code and interface with
the assembly backend is too (x86) specific (and possibly too RISC-V
specific when using the riscy-arch flag?).

If we can get rid of the specifics an unify into a clean mescc->as
interface, that would be amazing.

Greetings,
Janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com