Permalink
Reply
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.)