This commit re-arranges the internal plumbing of QBE to allow support
for 32-bit targets. Previously, there was a significant amount of code
that assumed that word sizes/register sizes would always be Kl (8
bytes). This commit aims to remove those assumptions.

A new field is added to "struct Target" named "align". The word size of
the target is defined as "2^align" bytes. For all existing targets (i.e.
64-bit targets) it is set to 3.

This commit then changes the machinery in "parse.c" to accomodate the
new "align" field. Firstly, "Km" is no longer an alias for "Kl", and the
resulting operations are set appropriately. Second, if it detects the
usage of "Kl" in any of the instructions and "T.align" is less than 3,
it will raise an error. This is in line with previous discussion on how
[message trimmed]

 > for a proof of concept, I'd start with simply erroring on 64 bit
 > types; once that's done, it's easy to experiment with how to deal
 > with them.

One additional note of complexity here. A lot of QBE is predicated on
the target's word alignment being 2^3. See the "NAlign" constant in
"all.h" and the various places in code labeled with this comment:

     /* specific to NAlign == 3 */

I am currently working on this, by the way, but my plan is to submit a
patch that adds an i386 backend along with the rest of this.

+1 to this. I encountered this issue during monomorphization of Rust
types in Dozer.

>> I'm probably missing some arch fu, but why is this an issue? x86
>> (non-64-bit) always supported 80-bit fp, so double-precision fp is not
>> obviously an issue.
> 
> Ditto ARM32, sorry the above was too platform-specific. RiscV has
> specific opt-in support for float/'s' and double/'d' precision fp. I
> presume it's up to the frontend to decide how to implement this.

Ah, if there's a way to do this that would make sense. My main concern
would be ABI issues. Not sure how easy it is to lower an "l" to two "w"
parameters.

On 12/24/24 00:54, Roland Paterson-Jones wrote:

> So from the cproc frontend perspective it might be easier to (still)
> generate 'l' for long long on 32/32-bit, but map pointer/long types to
> 32-bit ('w'), and handle 'l' lowering in the QBE backend.

I'm fine with this, I don't think it would be *that* much extra code.
One extra pass at most. My main issue is: should we also handle lowering
'd' to 's' in QBE? I'm not sure about this one since it would mean
significantly more code, since we would effectively need to rewrite
softfp in QBE IR.

> I don't believe C needs it for anything.

C needs it for the top-level "asm" macro, right?

I guess you can push it into a ".S" file and compile that into the
executable, but that seems kind of hacky.

> It would involve a lot more than that, since wasm doesn't allow
> arbitrary control flow graphs.

That's fair, I suppose. It's the kind of thing I haven't put much
thought into yet.

Would WebAssembly support be desired for QBE? It would mean rewriting a
lot of "emit.c" and others, since WebAssembly is not assembled via GAS
or NASM but with WABT, which has an S-Expr-like format.

This patch adds module-level inline assembly. The main idea is to
introduce an "asm" keyword, which takes a string which is echoed
straight into the output file. The only post-processing done on the
string is escaping it.

This feature roughly corresponds to the top-level "asm" macro in most C
compilers or the "global_asm!" macro in Rust. I've added documentation
of this feature to "il.txt" as well.

I have not implemented instruction-level inline assembly, since it is
more controversial and will likely impact more of the codebase.

This is my first patch for this codebase. I may not be aware of some
code idioms.
[message trimmed]

> i'm not sure this is all that helpful from hare's perspective

I believe it is impossible to implement certain constructs in C and Rust
without this feature. This patch is mostly intended for them. If Hare
doesn't use it, that's okay.

Also, I appear to have messed up the patch formatting. git send-email
wasn't working for me, so I foolishly tried to just paste the patch into
Thunderbird and send it on. Let me try again.