Static memory allocation requires hardcoding an upper limit of size of everything. For example, if you limit each string to be at most 256 bytes, then a string with only 10 bytes will waste 246 bytes of memory.
If you limit string length to 32 bytes it will waste fewer memory but when a string longer than 32 bytes comes it cannot handle.
> if you limit each string to be at most 256 bytes, then a string with only 10 bytes will waste 246 bytes of memory.
No? Unless you limit each string to be exactly 256 bytes but that's silly.
> If you limit string length to 32 bytes it will waste fewer memory but when a string longer than 32 bytes comes it cannot handle.
Not necessarily. The early compilers/linkers routinely did "only the first 6/8 letters of an identifier are meaningful" schtick: the rest was simply discarded.
Yes, you can dump your IR straight to the disk and then stream it to process further. That's how quite a number of compilers (and assemblers) were written back in the 70s and it was quite painful.
IIRC, Unix's original as works that way: during assembly, the text and data sections are written into separate temporary files, and then they are merged together into the a.out. And yes, it's slow.
How does static allocation avoid wasting memory?
Static memory allocation requires hardcoding an upper limit of size of everything. For example, if you limit each string to be at most 256 bytes, then a string with only 10 bytes will waste 246 bytes of memory.
If you limit string length to 32 bytes it will waste fewer memory but when a string longer than 32 bytes comes it cannot handle.
> if you limit each string to be at most 256 bytes, then a string with only 10 bytes will waste 246 bytes of memory.
No? Unless you limit each string to be exactly 256 bytes but that's silly.
> If you limit string length to 32 bytes it will waste fewer memory but when a string longer than 32 bytes comes it cannot handle.
Not necessarily. The early compilers/linkers routinely did "only the first 6/8 letters of an identifier are meaningful" schtick: the rest was simply discarded.
Yes, you can dump your IR straight to the disk and then stream it to process further. That's how quite a number of compilers (and assemblers) were written back in the 70s and it was quite painful.
IIRC, Unix's original as works that way: during assembly, the text and data sections are written into separate temporary files, and then they are merged together into the a.out. And yes, it's slow.