3 ms·

I stick to lean and simple C89 with benign bits of c99/c11. With nice tables of functions and clever recursive pre-processor naming, you can scale that easily t

I stick to lean and simple C89 with benign bits of c99/c11. With nice tables of functions and clever recursive pre-processor naming, you can scale that easily to large modular applications and keep everything very clean. The absolute and unquestionable truth: a c++ compiler is abysmally more complex and hard to write than a C (89 with benign bits of c99/c11) compiler, and this is mecanically true due to the syntax complexity difference. There are many shmol and cute alternatives C compilers out there (and there are working better each day which goes by, and some are doing more than enough optimizations), and I would like to use them, that which is not possible with c++, due to its complexity hence shuting the door hard on any reasonable efforts of writing a "working" alternative. That said, personnaly, I have high hopes (maybe too high) if RISC-V is successful: I see everything assembly (not even C anymore) with high level script languages of the like of python/javascript/lua/etc. I am writting more and more assembly these days (mostly x86_64 though, desktop RISC-V are only starting to ramp up in performance), and the main pitfall seems to be the abuse of the macro language of the assembler, which could be averted if explicitely aware of this bias.

throwaway17_17 5y ago
Can you expand a little on the pitfalls you see concerning the 'abuse of the macro language'? I have an undeniable pipe dream that my hobby language can be essentially a well-defined and explicit thin cover for assembly language primitives. I think your thoughts about the downsides of 'higher-level' idioms/practices when using assemblers would be very on point for me to consider.
- sylware 5y ago
  I use FASM, and FASM has probably one of the most powerfull macro languages out there. FASM actually implements _only_ this macro language and _not_ the x86_64 assembler itself. The x86_64 assembler is actually written using this macro language, like the support of ELF, COFF, etc, binary formats. Some ppl have implemented an ARM assembler with this macro language (and I am thinkink about RISC-V). Its author likes to refer to this macro language as an "assembler writting toolkit" which looks to me more than fair. As a practical example, this macro language has full support of modular and hierarchical namespaces. I found myself lost into dividing my code paths in basillions of namespaces and that way too much. Excessively, I also started to write my "own" language using this macro language: I was not writting assembly anymore, only macros and some with hardly any assembly in them. This is actually a bias that happens with any computer language: the tendency of devs to "maximize" the usage of some syntax, which kind of increase exponentially with this very syntax complexity, to reach a point where a Rube Goldberg machine looks efficient and sane (yes, this is severe irony).

throwaway17_17 5y ago

Can you expand a little on the pitfalls you see concerning the 'abuse of the macro language'? I have an undeniable pipe dream that my hobby language can be essentially a well-defined and explicit thin cover for assembly language primitives. I think your thoughts about the downsides of 'higher-level' idioms/practices when using assemblers would be very on point for me to consider.

sylware 5y ago
I use FASM, and FASM has probably one of the most powerfull macro languages out there. FASM actually implements _only_ this macro language and _not_ the x86_64 assembler itself. The x86_64 assembler is actually written using this macro language, like the support of ELF, COFF, etc, binary formats. Some ppl have implemented an ARM assembler with this macro language (and I am thinkink about RISC-V). Its author likes to refer to this macro language as an "assembler writting toolkit" which looks to me more than fair. As a practical example, this macro language has full support of modular and hierarchical namespaces. I found myself lost into dividing my code paths in basillions of namespaces and that way too much. Excessively, I also started to write my "own" language using this macro language: I was not writting assembly anymore, only macros and some with hardly any assembly in them. This is actually a bias that happens with any computer language: the tendency of devs to "maximize" the usage of some syntax, which kind of increase exponentially with this very syntax complexity, to reach a point where a Rube Goldberg machine looks efficient and sane (yes, this is severe irony).