And... just to close, I'll change my mind again, for the new year :)

On Tue, Dec 24, 2024 at 10:54 AM Roland Paterson-Jones
<rolandpj@gmail.com> wrote:
>
> On Tue, Dec 24, 2024 at 10:19 AM Roland Paterson-Jones
> <rolandpj@gmail.com> wrote:
>
> > > The linked thread seemed to settle on forbidding `l` altogether
> >
> > This is definitely the simplest solution for 32/32-bit architectures

> I took a quick look at cproc, and might change my mind now :)
>

Nice! Haven't looked at it in much detail but yes, agreed that the
various "assumes align == 3" are somewhat opaque to me too.

Minor quibble - I prefer the term "order" (size is 1 << order) instead
of "align", following linux practice, but understand the QBE heritage.

On Fri, Jan 3, 2025 at 6:51 PM John Nunley <dev@notgull.net> wrote:

> This commit then changes the machinery in "parse.c" to accomodate the

My personal favourite misspelling of accommodate :)

> Finally, this commit removes "NAlign"

> Is it possible to increase this [NString] cap from 80 characters?

On Fri, Jan 3, 2025 at 6:28 PM John Nunley <dev@notgull.net> wrote:
>
> +1 to this. I encountered this issue during monomorphization of Rust
> types in Dozer.

Just note that QBE "named" structures are coded to include the max
NString size in the struct itself (always).

https://c9x.me/git/qbe.git/tree/all.h#n237
https://c9x.me/git/qbe.git/tree/all.h#n322
... etc.

On Tue, Dec 24, 2024 at 7:34 PM Roland Paterson-Jones
<rolandpj@gmail.com> wrote:

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

I do remember some ARM32 arch's supporting fp ops transparently
through instruction trapping (StrongArm?) This was a while ago tho -
previous millennium :P

Hey John, and season's greetings to anyone listening.

On Tue, Dec 24, 2024 at 7:30 PM John Nunley <dev@notgull.net> wrote:
>
> 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.

Ack.

On Tue, Dec 24, 2024 at 10:19 AM Roland Paterson-Jones
<rolandpj@gmail.com> wrote:

> > The linked thread seemed to settle on forbidding `l` altogether
>
> This is definitely the simplest solution for 32/32-bit architectures
> like ARM32/x86. I haven't looked, but it might be instructive to look
> at cproc - https://github.com/michaelforney/cproc - and get an idea of
> how much pain is involved in generating 'w' ops for memory addresses.
> This could drive more concrete discussion on potential QBE
> changes/enhancements.

I took a quick look at cproc, and might change my mind now :)

Hey Alex, some half-baked thoughts following on from the "8/16-bit Z80
support" thread
https://lists.sr.ht/~mpu/qbe/%3CCABdyTNG=ru7YTd32KbJYXv8xzO8iwbU8c=z4LcW2en0yhzWXDQ@mail.gmail.com%3E.

On Tue, Dec 24, 2024 at 9:52 AM Alex // nytpu <alex@nytpu.com> wrote:

> The main problem is, while 32-bit architectures in QBE are solved in
> theory ("just use `w` instead of `l` for pointers"), it seems to be to
> not really be solved in practice...
> Seems like I'd have to convince every frontend to do potentially
> quite a bit of work

Indeed.

On Sat, Dec 7, 2024 at 6:11 PM Roland Paterson-Jones <rolandpj@gmail.com> wrote:

> I wonder if it would just work to use "w" (32-bit) everywhere

Hrmm, this boils down to assuming a 16-bit arch, which precludes the
use of z80 "a" register completely - except for necessary use in
load/store.

That definitely seems like a bad fit :(

Hi Atirut

On Sat, Dec 7, 2024 at 5:43 PM Atirut Wattanamongkol
<atirut.wattanamongkol@gmail.com> wrote:

> I’ve been working on a C compiler that targets the Z80

Cool! Why? I was very familiar with the z80[a] about 50 years ago via
the amazing Sinclair ZX80/1 and Spectrum products.

> [QBE]
> Any pointers?

Roberto E. Vargas Caballero <k0ga@shike2.com> wrote:

On Thu, Aug 29, 2024 at 10:53 AM Roland Paterson-Jones
<rolandpj@gmail.com> wrote:
>
> Changes since RFC 8:
>
Please note that I found a rare, but serious, bug in GCM - again,
use-before-def.

I have a fix, which I'll post as (part of) a new RFC rev real soon now...