Re: [bug-mes] mescc and Load/Store architectures

[Jeremiah]

> Jeremiah, who are the users of the following chunk?
> if(40 == Architecture) outputPointer(displacement - 7, 1); /* Deal with ! */
That would be only a single first round attempt for Arm immediates in
mescc-tools that can be replaced entirely.

> But that would mean that we couldn't ever store byte-offset
> displacements (for example for load/store instructions).
> That could be fine, though.  Is it?
But as having only written this assembly code for ARM:
https://github.com/oriansj/mescc-tools/blob/master/test/test11/hello.M1

If you are willing to be responsible for the ARM port, you can do
anything you want to the ARM specific rules.

> But why is the following special case in storePointer rather than in
> Architectural_displacement ?
%label was correct with the Architectural displacement but !label didn't
agree with that calculation and I saw no issue with different sized
relative pointers having different calculations.

> Mes seems to assume CISC architecture at least partially and I'm
> having a hard time emulating all the CISC-specific instructions
Could you please take a look at this set:
https://github.com/oriansj/M2-Planet/blob/master/test/common_x86/x86_defs.M1
As Getting M2-Planet to ARM will help get Mescc's bootstrap on ARM as
well and they can share the exact same operations.

> That could be a feature, it could even reduce the alphabet specified
> in x86.M1.  Not sure if a performance loss, if any, is relevant.
Well reducing the alphabet would simplify porting and performance isn't
critical in Mescc's produced binaries; otherwise we would be adding
deterministic optimization passes to Mescc.

-Jeremiah