bug-mes
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: porting efforts


From: Gabriel Wicki
Subject: Re: porting efforts
Date: Thu, 3 Feb 2022 16:21:22 +0100

Hello!

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


I have some more questions, and some proposals, but i'd like to hear
your opinion first.



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.

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


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... ;)



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.

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?


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.


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?



Kind regards + best wishes
gabriel



0: https://github.com/gbrlwck/mes-m2 (this code is not ready yet but you
might get an idea)

On Thu, Dec 09, 2021 at 02:03:22PM +0100, Jan Nieuwenhuizen wrote:
> Jan Nieuwenhuizen writes:
> 
> > Also, you could have a look at arm.scm, it already has some comments.
> 
>     module/mescc/armv4/as.scm
> 
> is of course what I meant.
> 
> -- 
> Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
> Freelance IT http://JoyofSource.com | Avatar?? http://AvatarAcademy.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]