3 ms·

> Nobodys fault really, but bad results ensued. Uh, the fault is entirely in writing an assembler _that is not an assembler_, but rather something that is _alm

> Nobodys fault really, but bad results ensued. Uh, the fault is entirely in writing an assembler _that is not an assembler_, but rather something that is _almost_ like one but then 1% like an IR instead. It's an unforced error.

wbl 1y ago
Assemblers used to do a ton of stuff back in the day
- anyfoo 1y ago
  Oh yeah. S/360 assembly almost looks like a high level language sometimes. In MVS, functions of the OS and standard libraries (or its equivalent) were implemented as elaborate macros, with their own invocation syntax, whereas nowadays you'd expect a function that you'd call (dynamically linked or not), with parameters passed in registers. At least in the 90s, there were actually macro assemblers that supported OOP programming in assembly. Borland Turbo Assembler 5.0 comes to mind, if was kind of fun.
  - pjmlp 1y ago
    Those are still around if you go for Assemblers with background in PC culture like NASM, YASM, MASM (still part of MSVC). By the way Embarcaredo still has Turbo Assembler. https://docwiki.embarcadero.com/RADStudio/Athens/en/Turbo_Assembler_Options https://docwiki.embarcadero.com/RADStudio/Athens/en/Turbo_As... Now a thing of the past, but Assemblers for game consoles were also quite powerfull in their macro capabilities. I never liked the UNIX Assembly culture, because naturally as soon as C became a thing, they became the bare minimum required to assemble the generated Assembly out of the C compiler, as another step into the compilation pipeline. All the niceties of macro assemblers came through the other platforms, like being able to use NASM instead of the platform assembler, not even GNU AS nor clang are that great in their abilities as Assemblers beyond the basic stuff.
whizzter 1y ago
It doesn't even need to be an error in the "assembler" but could be another part that converts from some internal highlevel IR, also for most cases split ops doesn't matter for register manipulating instructions (that you might want generated as compactly as possible) since regular atomics are separate on memory addresses. Even then, if the code-gen was written BEFORE the preemption then it was fairly sloppy for those implementing the preemption to not consider the function epilogue, granted statically adjusting the stack/frame pointer by more than 4kb is probabably a tad of an edge-case.

wbl 1y ago

Assemblers used to do a ton of stuff back in the day

anyfoo 1y ago
Oh yeah. S/360 assembly almost looks like a high level language sometimes. In MVS, functions of the OS and standard libraries (or its equivalent) were implemented as elaborate macros, with their own invocation syntax, whereas nowadays you'd expect a function that you'd call (dynamically linked or not), with parameters passed in registers. At least in the 90s, there were actually macro assemblers that supported OOP programming in assembly. Borland Turbo Assembler 5.0 comes to mind, if was kind of fun.
- pjmlp 1y ago
  Those are still around if you go for Assemblers with background in PC culture like NASM, YASM, MASM (still part of MSVC). By the way Embarcaredo still has Turbo Assembler. https://docwiki.embarcadero.com/RADStudio/Athens/en/Turbo_Assembler_Options https://docwiki.embarcadero.com/RADStudio/Athens/en/Turbo_As... Now a thing of the past, but Assemblers for game consoles were also quite powerfull in their macro capabilities. I never liked the UNIX Assembly culture, because naturally as soon as C became a thing, they became the bare minimum required to assemble the generated Assembly out of the C compiler, as another step into the compilation pipeline. All the niceties of macro assemblers came through the other platforms, like being able to use NASM instead of the platform assembler, not even GNU AS nor clang are that great in their abilities as Assemblers beyond the basic stuff.

whizzter 1y ago

It doesn't even need to be an error in the "assembler" but could be another part that converts from some internal highlevel IR, also for most cases split ops doesn't matter for register manipulating instructions (that you might want generated as compactly as possible) since regular atomics are separate on memory addresses. Even then, if the code-gen was written BEFORE the preemption then it was fairly sloppy for those implementing the preemption to not consider the function epilogue, granted statically adjusting the stack/frame pointer by more than 4kb is probabably a tad of an edge-case.