3 ms·

I had similar intentions - I was deep into OS development back then, so I wanted to have a 32-bit C/C++ compiler that would effortlessly target 80386+ CPUs. Bo

I had similar intentions - I was deep into OS development back then, so I wanted to have a 32-bit C/C++ compiler that would effortlessly target 80386+ CPUs. Borland C++ was my favorite one because it supported official x86 assembly syntax (Intel). In contrast, GNU tools of the day had their own kinky x86 syntax which made me uneasy. It so happened that the Borland compiler that was able to target a 32-bit CPU, required a 32-bit CPU itself to run. DOS only provided 16-bit environment. That's why I went to those lengths of writing a custom 32-bit PE loader that would allow me to run some 32-bit Windows applications right under the DOS. DOS was a preferable environment because it was fast and allowed booting your own OS kernels without doing a full computer reboot - you just ran an executable loader and it took control away from the DOS and gave it to your OS. And then when you "exited" your OS, instead of rebooting, it was returning back to the DOS provided that the OS kernel you were running was careful enough to preserve/restore the RAM content upon exit. It gave a huge productivity boost back then. Later, however, I switched to Windows and was using Bochs (open-source x86 PC emulator) to effortlessly run the OS I was working on.

pjmlp 3y ago
I never could stomach the inline Assembly syntax from GNU tools, having been educated in Borland and Microsoft compilers. Nowadays, if I would have to write that kind of code, I would rather use intrisics or go to the trouble of using an external Assembler.
- garganzol 3y ago
  I once asked GNU people why they had such weird non-standard syntax for inline x86 assembly. Their answer was that the GNU syntax was just easier to implement in their existing toolchain of the day. Their big idea was to have a semi-universal implementation of the assembler where a particular CPU syntax was just a small, mostly declarative piece of code and configuration. The support of the canonical Intel syntax for x86 assembly would require significantly more efforts. As far as I know, the idea of a weird but universal assembly syntax came from the original Unix developed by AT&T. My take was: come on, it's just a syntax, a relatively miniscule effort required to implement the idiomatic x86 assembly support is nothing compared to pains a custom non-standard syntax may give to people.

pjmlp 3y ago

I never could stomach the inline Assembly syntax from GNU tools, having been educated in Borland and Microsoft compilers. Nowadays, if I would have to write that kind of code, I would rather use intrisics or go to the trouble of using an external Assembler.

garganzol 3y ago
I once asked GNU people why they had such weird non-standard syntax for inline x86 assembly. Their answer was that the GNU syntax was just easier to implement in their existing toolchain of the day. Their big idea was to have a semi-universal implementation of the assembler where a particular CPU syntax was just a small, mostly declarative piece of code and configuration. The support of the canonical Intel syntax for x86 assembly would require significantly more efforts. As far as I know, the idea of a weird but universal assembly syntax came from the original Unix developed by AT&T. My take was: come on, it's just a syntax, a relatively miniscule effort required to implement the idiomatic x86 assembly support is nothing compared to pains a custom non-standard syntax may give to people.