On Wednesday, 5 April 2023 at 15:19:55 UTC, Cecil Ward wrote:
How much code do you thing I would need to write for this? I’m
still thinking about its feasibility. I don’t want to invent
the wheel and write a custom parser by hand, so’d rather steal
the code using sim eg called ‘a library’. :-)
The idea would be that the user could run this to sanity-check
her understanding of the sometimes arcane GDC asm code
outputs/inputs/clobbers syntax, and see what her asm code’s
constraints are actually going to do rather than what she
thinks it’s going to do. Clearly I can’t readily start parsing
the asm body itself, I would just inspect the meta info. (If
that’s the right word?)
I would have a huge problem with LDC’s alternative syntax
unless I could think of some way to pre-transform and munge it
into GDC format.
I do wish LDC (and DMD) would now converge on the GDC asm
syntax. Do you think that’s reasonably doable?
Maybe try a translator approach? A GDC/LDC to the other(or a
custom format, maybe even NASM with comments explaining what the
inline assembly metadata says) translator(assuming x86 here, but
at a glance it seems ARM is affected by similar MASMvsAT&T and
compiler inline assembly nightmare fuel) would probably help,
especially considering you appear to prefer GDC's inline asm to
LLVM's.
As for the amount of effort, it will possibly require a few
structs to represent an intermediary format(maybe) and pattern
matching routines to convert to that format.
On a more personal note, i was faced with the same
dissatisfaction you appear to be having and found great success
with NASM, it was easier to write code for it and also helps get
one familiarized with usage of D/dub in cross language projects.
It's also compatible with DMD by virtue of being compiler
independent.
Using the D-integrated `asm` statement may work but it certainly
lacks support of too many instructions and registers for me to
recommend using it.(unless this changed.)