It's a long time ago that I last wrote 8086 assembler.
The OP speaks of the assembler not freeing allocated memory, and refers to "manual calls to free". Back in the day, memory management was the programmer's responsibility; I don't know how an assembler might divine the programmer's intention.
Like, you could allocate stack memory in assembler, and deallocate it simply by returning. But heap management would be the responsibility of some library or OS (and the stuff I wrote ran on bare metal, this was before Windows).
I read that part as the assembler itself never freeing memory during its work assembling. The assembled program can do whatever including using the stack and manual memory management.
I wrote a crude assembler in Pascal once (for fun). It didn't need a heap, it was all static allocation and stack - it didn't cross my mind that one might write an assembler that needs to do heap allocation. I was a callow youth, and probably didn't know what a heap was!
The only storage you need other than stack is for a symbol table. In the general case, you can't know in advance how big that's going to be, so I suppose heap allocation for the symbol table makes sense.
May be 6502 is just simplifier. But dealing with basic memory, asm, machine code, cpu and flags are so intuitive when you got a javascript emulator using canvas.
A word of warning for those wondering: this is not for Intel syntax, despite referencing the Intel doc.
Minias can assemble itself
...but it's written in C and uses a parser generator? IMHO it feels a bit backwards --- and perhaps even a bit cheating if you're doing this for a "bootstrap pilgrimage" --- to write a lower-level tool in a higher-level language. On the other hand, the same author also links to a C compiler in C, without a parser generator: https://github.com/michaelforney/cproc
I don't know why you would think referencing Intel's x86 software developer manual has anything to do with what syntax an assembler would use. Anyone writing an assembler, regardless of its input syntax would refer to it.
> ...but it's written in C and uses a parser generator? IMHO it feels a bit backwards --- and perhaps even a bit cheating if you're doing this for a "bootstrap pilgrimage"
Who says they share your goals? It says they wrote this just for "fun and learning," i.e. to learn how an assembler works and how x86 instructions are encoded, maybe even to practice their C.
That is how I read it. This is intended to be paired with cproc, a c compiler that uses QBE for it’s backed. QBE outputs assembly not binaries, so an assembler could be used to assemble itself as part of that toolchain.
Author here, that's exactly what I meant. It can also assemble the cproc C compiler when it compiles itself - thus creating a loop. I updated the readme.
First there is perhaps some slight refactoring that could be done. Though it does sound nice to reduce the dependency tree.
One thing is I like the declarative nature of the peg,
so I considered trying to make a tiny peg parser generator to go with it (Also worth noting that peg/leg itself is very small).
All that being said, a hand written parser could probably dramatically increase performance and not be that much more code - so I am still unsure - but probably.
The OP speaks of the assembler not freeing allocated memory, and refers to "manual calls to free". Back in the day, memory management was the programmer's responsibility; I don't know how an assembler might divine the programmer's intention.
Like, you could allocate stack memory in assembler, and deallocate it simply by returning. But heap management would be the responsibility of some library or OS (and the stuff I wrote ran on bare metal, this was before Windows).