Re: [bug-mes] MesCC should optimize ease of convincing us of its correctness

[Danny Milosavljevic]

Hi Janneke,

Am Sat, 27 Jul 2019 09:21:33 +0200
schrieb Jan Nieuwenhuizen <address@hidden>:

> I just remembered that I added an align flag to mescc
> 
>   --align             align globals
> 
> because the alignment code that I wrote broke either some tests or
> running tcc.  So this is one of these things that needs more
> thought and a some nice tests.

Hmm, I've checked it out but I don't understand yet what the goal of
the existing aligner is.

The client module for "align?" seems to be only module/mescc/M1.scm,
function "display-align", which is local to "write-global".  Also, it
seems to do the alignment afterwards--which I haven't ever seen before.

The reason aligned accesses are done on RISC is in order to make the
data bus accesses simpler by requiring the entire operand, no matter
how small, to be able to be transferred with one data access and without
shifts.
The ARM data bus is 32 bit.

(Historically, ARM used to use the unused-for-the-above-purpose low bits of
registers for other purposes.  For example the low 2 bits of the program
counter were used for processor flags.  That's dirty but that's how it was)

Likewise, interfaces for executing units for larger operands would just
[have to] support (for example) a quadword data bus and nothing else.
Then those instructions requiring larger operands would require their
operands to be aligned to this larger granularity (for example quadwords).

So basically, I've always thought of alignment being a property of the
(new) field and current output position, and to be done BEFORE both the field
and its label is emitted. 

Some examples:

-----------------
char a;
int b; // this causes the start address of b be aligned to sizeof(int).
//(i.e. b's start address to be a multiple or sizeof(int))
-----------------
char a;
double b; // this causes the start address of b be aligned to sizeof(double).
//(i.e. b's start address to be a multiple or sizeof(double))
------------------

All in all I guess if the alignment is always the same we can also do the
fixups as paddings at the end (like we do right now)--but I wouldn't recommend
it (in order to make it future-proof).  This simplification basically only
works if we assume that there is only one data bus for all the execution units.

But how does your existing implementation do "struct" alignment?

The only important part of structure alignment is the alignment of the structure
members.  I would even argue that the structure itself is explicitly supposed to
be NOT aligned (because the CPU doesn't know that C structures exist--and it
shouldn't need to).

So if one does this:

-----------------
char a;
struct {char x[16];} b; // this SHOULD NOT cause the start address of b be 
aligned to sizeof(struct {char x[16];}).

pgp4PKTwHJ10e.pgp
Description: Digitale Signatur von OpenPGP