> I'd like to keep syntactic sugar out of the IL.
A respectable choice.
> I suggest you have a single way of emitting loads and stores
I have exactly that, but they operate on syntax nodes. There are a few
places in the codegen that implicitly load a field.
(Examples: Bounds checking, tagged unions)
> and maybe add a comment in the generated IL that makes it clear for
> you what's happening.
I initially solved my problem by _removing_ all comments and rewriting
the loads/stores to encode their own offsets.
That made the problem clear to me, and hence the patch.
(Side note: debug info would have really helped as well)
---
Anyway, I have fixed (most) codegen bugs quite a while ago now, and my
codegen does not produce QBE syntax, but a QBE compatible representation
(to allow for compile time execution, bounds checking, etc.).
I can easily continue doing the syntactical sugar on my end, and
although I think this syntactical sugar might help people, I respect
your choice to keep the QBE IR simple, that is after all why I chose to
use it in the first place :)
Hi,
That is not getting in qbe, or any variation on the theme. I'd like to keep syntactic sugar out of the IL and consider it rather like some human readable serialization format, faithfully reflecting the internal representation.
For your readability problem I suggest you have a single way of emitting loads and stores, and maybe add a comment in the generated IL that makes it clear for you what's happening.
Best