5 ms·

You want a macro assembler. C is not a macro assembler. C was never supposed to be a macro assembler. It was designed as a cross platform language, which fundam

You want a macro assembler. C is not a macro assembler. C was never supposed to be a macro assembler. It was designed as a cross platform language, which fundamentally means you are programming to an abstract machine, which necessarily means that you cannot have an macro assembler [0]. I can, however, see an argument that people want a C like language which is a macro assembler. I am lost again when people start asking for a C++ like macro assembler. The features that C++ brings over C are not concepts that exist on any mainstream CPU. [0] Unless you decide to build a concrete machine (either in bare metal, or as a VM).

co_pilates 5y ago
Have any good sources of this topic of macro assemblers? I'm interested in reading about this type of thing. I'll search Google, but you can't always find good sources there today.
- gizmo686 5y ago
  Unfourtuantly not. The only one I have worked with was really just a normal assembler with a big library of in house macros.
  - lokedhs 5y ago
    I searched a bit, and found a large set of pages with information on the topic in the context of the 360 architecture. I'd say this architecture is unique in that it is still to this day used to write high level software. Put "360 assembler macros" in your search engine and you'll find lots of information. This is a good place to start: https://www.ibm.com/docs/en/zos/2.1.0?topic=language-macro-instructions https://www.ibm.com/docs/en/zos/2.1.0?topic=language-macro-i...
- pjmlp 5y ago
  Yeah, plenty of books at archive.org. "Assembly language for the PC" https://archive.org/details/assemblylanguage00soch https://archive.org/details/assemblylanguage00soch "TASM Reference" https://archive.org/details/bitsavers_borlandturemblerVersion4.0QuickReferenceMar94_5680156 https://archive.org/details/bitsavers_borlandturemblerVersio... "Structured Assembler Language For IBM Microcomputers" https://archive.org/details/structured-assembler-language-for-ibm-microcomputers https://archive.org/details/structured-assembler-language-fo... Or just go to MASM documentation, you will find plenty of directives that look like an high level language https://docs.microsoft.com/en-us/cpp/assembler/masm/directives-reference?view=msvc-160 https://docs.microsoft.com/en-us/cpp/assembler/masm/directiv...
overgard 5y ago
C was originally a macro assembler! This new mutation of C is just that, new. I don't mind optimizations as long as it doesn't remove intent, which is usually clearly indicated in the source, standards be damned.
- gizmo686 5y ago
  How far back to you want to go? There is no definitive start point for C, as it grew fairly organically out of B and began as a living language. However, a reasonable approximation for C 1.0 is The C Programming Language (Kernighan and Ritchie, 1978) [0], commonly known as K&R C. The language they describe is much simpler than modern C. Notably for this discussion, it contains no synchronization mechanisms. There is nothing in that book that suggests C was a macro assembler. On the contrary, its description of C precludes it from being a macro assembler for the reasons I talked about in a parent comment: > Although C matches the capabilities of many computers, it is independent of any particular machine architecture, and so with a little care it is easy to write "portable" programs, that is, programs which can be run without change on a variety of hardware. . It is now routine in our environment that software developed on UNIX is transported to the local Honeywell, IBM and Interdata systems. In fact, the C compilers and runtime support on these four machines are much more compatible than than the supposedly ANSI standard versions of Fortran. > Because the data types and control structures provided by C are supported directly by most existing computers, the runtime library required to implement self-contained programs is tiny. On the PDP-I1, for example, it contains only the routines to do 32-bit multiplication and division and to perform the subroutine entry and exit sequences. Notice the way this paragraph frames the issue. Since the features of C are supported by most machines, it can be implemented with a small runtime library. It does not say that C must use those features directly. In fact, it explicitly anticipates that C could provide some of its primitives in ways other then directly leveraging a corresponding capability of the hardware. The feature here is efficiency and a small runtime. [0] https://1lib.us/book/2660358/b1a4cf https://1lib.us/book/2660358/b1a4cf
- stormbrew 5y ago
  I'm not sure where you got that idea. C was never ever a macro assembler, and its antecedent language (B[1]) is actually even more abstracted away. C was a slight lowering, not a raising, of hardware abstraction. If C were a macro assembler the following things would be true of it, most likely: - types would have fixed bit sizes (ie. uint32_t would be the norm) - you'd be able to do various 'normal' things for assembly like rotate left and right. - inline assembly would probably be.. you know.. standard instead of something that compiler vendors only started putting in in like the 80s. You might be thinking of the fact that C++ was originally sort of a Macro C (aka Cfront)? [1] Ever wondered why `int` is so fuzzily defined in C? It's because in B there was only one type and it was always word sized. That's also why various things are typed `int` by default if you don't specify.
benibela 5y ago
Unfortunately, classes teaching C often start with telling people that with C they learn how the real machine and the real CPU works on the lowest levels.
- weeblewobble 5y ago
  I'd be surprised if this was true. It certainly doesn't match my experience, and it also doesn't really make sense. The difference between machine code, assembly, and programming languages like C is first-week CS 101 stuff. What are you basing this on?

co_pilates 5y ago

Have any good sources of this topic of macro assemblers? I'm interested in reading about this type of thing. I'll search Google, but you can't always find good sources there today.

gizmo686 5y ago
Unfourtuantly not. The only one I have worked with was really just a normal assembler with a big library of in house macros.
- lokedhs 5y ago
  I searched a bit, and found a large set of pages with information on the topic in the context of the 360 architecture. I'd say this architecture is unique in that it is still to this day used to write high level software. Put "360 assembler macros" in your search engine and you'll find lots of information. This is a good place to start: https://www.ibm.com/docs/en/zos/2.1.0?topic=language-macro-instructions https://www.ibm.com/docs/en/zos/2.1.0?topic=language-macro-i...
pjmlp 5y ago
Yeah, plenty of books at archive.org. "Assembly language for the PC" https://archive.org/details/assemblylanguage00soch https://archive.org/details/assemblylanguage00soch "TASM Reference" https://archive.org/details/bitsavers_borlandturemblerVersion4.0QuickReferenceMar94_5680156 https://archive.org/details/bitsavers_borlandturemblerVersio... "Structured Assembler Language For IBM Microcomputers" https://archive.org/details/structured-assembler-language-for-ibm-microcomputers https://archive.org/details/structured-assembler-language-fo... Or just go to MASM documentation, you will find plenty of directives that look like an high level language https://docs.microsoft.com/en-us/cpp/assembler/masm/directives-reference?view=msvc-160 https://docs.microsoft.com/en-us/cpp/assembler/masm/directiv...

overgard 5y ago

C was originally a macro assembler! This new mutation of C is just that, new. I don't mind optimizations as long as it doesn't remove intent, which is usually clearly indicated in the source, standards be damned.

gizmo686 5y ago
How far back to you want to go? There is no definitive start point for C, as it grew fairly organically out of B and began as a living language. However, a reasonable approximation for C 1.0 is The C Programming Language (Kernighan and Ritchie, 1978) [0], commonly known as K&R C. The language they describe is much simpler than modern C. Notably for this discussion, it contains no synchronization mechanisms. There is nothing in that book that suggests C was a macro assembler. On the contrary, its description of C precludes it from being a macro assembler for the reasons I talked about in a parent comment: > Although C matches the capabilities of many computers, it is independent of any particular machine architecture, and so with a little care it is easy to write "portable" programs, that is, programs which can be run without change on a variety of hardware. . It is now routine in our environment that software developed on UNIX is transported to the local Honeywell, IBM and Interdata systems. In fact, the C compilers and runtime support on these four machines are much more compatible than than the supposedly ANSI standard versions of Fortran. > Because the data types and control structures provided by C are supported directly by most existing computers, the runtime library required to implement self-contained programs is tiny. On the PDP-I1, for example, it contains only the routines to do 32-bit multiplication and division and to perform the subroutine entry and exit sequences. Notice the way this paragraph frames the issue. Since the features of C are supported by most machines, it can be implemented with a small runtime library. It does not say that C must use those features directly. In fact, it explicitly anticipates that C could provide some of its primitives in ways other then directly leveraging a corresponding capability of the hardware. The feature here is efficiency and a small runtime. [0] https://1lib.us/book/2660358/b1a4cf https://1lib.us/book/2660358/b1a4cf
stormbrew 5y ago
I'm not sure where you got that idea. C was never ever a macro assembler, and its antecedent language (B[1]) is actually even more abstracted away. C was a slight lowering, not a raising, of hardware abstraction. If C were a macro assembler the following things would be true of it, most likely: - types would have fixed bit sizes (ie. uint32_t would be the norm) - you'd be able to do various 'normal' things for assembly like rotate left and right. - inline assembly would probably be.. you know.. standard instead of something that compiler vendors only started putting in in like the 80s. You might be thinking of the fact that C++ was originally sort of a Macro C (aka Cfront)? [1] Ever wondered why `int` is so fuzzily defined in C? It's because in B there was only one type and it was always word sized. That's also why various things are typed `int` by default if you don't specify.

benibela 5y ago

Unfortunately, classes teaching C often start with telling people that with C they learn how the real machine and the real CPU works on the lowest levels.

weeblewobble 5y ago
I'd be surprised if this was true. It certainly doesn't match my experience, and it also doesn't really make sense. The difference between machine code, assembly, and programming languages like C is first-week CS 101 stuff. What are you basing this on?