4

There are various open source assemblers such as , , and . They have different pseudo-ops and macro syntaxes. For many open source projects, assembler is pre-processed to replace constants and platform conditionals.

What limitations would gcc have creating assembler assuming you can use all current attributes and #pragmas, excluding translation performance (compile/assemble to binary time)?

I am not talking about . 

 #define MOV(RA,RB)  (OXFEB10000UL | RA << 16 | RB)  
 #define ADD(RA,RB)  (OXFEB20000UL | RA << 16 | RB)  
 #define RET         (OXFEB7ABCDUL)  

 unsigned long add4[] __attribute(section(".text")) =
 {
    ADD(R0,R1),
    ADD(R2,R3),
    MOV(R1,R2),
    ADD(R0,R1),
    RET()
 };

I believe that using pointer arithmetic can allow simulation of . and other labels. Perhaps this is an XY problem; I am trying to understand why there are so many assemblers at all. It seems like everything can be done by the pre-processor and the assembler is really a programmer preference; or there is a technical limitation I am missing.

I guess this might be related to 'Something you can do with an assembler that you can't do with shell code'.

Edit: I have re-tagged this from C to compiler. I am interested in the technical details of an assembler. Is it simply a 1-1 translation and emitting relocations (as a compiler will) or is there more? I don't mean for people to code assembler as I have outlined above. I am trying to understand what the assemblers are doing. I don't believe there is a Dragon book for assemblers. Of course, the pre-processor can not create a binary by itself and needs additional machinery; it only translates text.

Community
  • 1
  • 1
artless noise
  • 21,212
  • 6
  • 68
  • 105
  • 1
    I don't see this working for x86. It's non-trivial to select the best encoding for a particular instruction, alignment would be tricky, and optimizing branch size would be completely impossible as far as I can tell. And in any case you'd be using a hammer on a screw. – harold Mar 17 '13 at 20:51
  • @Harold: Can you elaborate on how it won't work? For the x86, it would be much more complex and would require `byte` alignments. Does an x86 assembler have to keep large basic blocks in memory to produce op-codes? – artless noise Mar 17 '13 at 23:39
  • 1
    @Bill - The x86 has variable length instructions, and there is not a 1-1 relation between mnemonic and opcode. For example a "simple" MOV has over 20 different variations, like that `MOV AX,1` is different from `MOV other_reg,1`. – Bo Persson Mar 18 '13 at 08:59
  • 1
    @BillPringlemeir no, but it does end up keeping large blocks in memory in order to satisfy alignment constraints while optimizing branch size. It only *requires* byte-alignment but it really *likes* 16-alignment for some branch targets. – harold Mar 18 '13 at 09:32
  • You might find this manual of an ancient assembler useful. http://www.bitsavers.org/pdf/dec/pdp1/PDP-1_Macro.pdf – luser droog Mar 21 '13 at 20:48

2 Answers2

4

I think that XY Problem is a wrong description. The question is more "Concept A is needed to evaluate Concept B".

Concept A: What is an assembler?

See: Assemblers and Loader, by David Solomon. [some pearls of wisdom, some archaic trivia]

I very quickly discovered the lack of literature in this field. In strict contrast to compilers, for which a wide range of literature exists, very little has ever been written on assemblers and loaders.

An assembler consists of,

  • A Symbol table to facilitates linking through some object format.
  • Lexer and Parser for converting the text to a data structure or directly to machine code.
  • Does 2 passes for most efficient branch and sub-routine calling.
  • An opcode table.

An assembler is generally a 1-1 translation. However, often several variants of branches and calls will exist; generally known as long and short version. The opcode used will depend on the distance to the destination; a two pass compiler is needed to optimize forward branches.Alluded to by Harold

Concept B: Using the 'C' pre-processor as an assembler.

The best a 'C' pre-processor could emulate is a 1-pass assembler. A large class of CPU/instructions can be encoded like this; although the macros could be cumbersome. There would be no listings or xrefs, but most people would not miss those features. Also, the syntax would be odd due to limitation of the pre-processor. It would be difficult dealing with address fix-ups as labels would either re-use the 'C' symbol table by using pointers or a hand coded #define for the label offset. This limits this approach to anything but a basic block.

Large assembler Routines

Large assembler routines such as YUV/RGB transforms or MP3 decoding are highly unlikely to be used this way.

Multi-arch code

Multiple architecture code is quite common. For example an ARM wifi chip may have it's code embedded in a Linux kernel as firmware. It is possible that this technique could be useful here. However, using separate compilers/assembler for the different architectures and then using objcopy to embedded them is far more sane.

Self-modifying Code

This is probably the most useful. In fact many tools, such as linkers and loaders have high level functions which patch code at run time. It could also be used to conditionally change a routine at runtime; function pointers are almost as fast and easier to understand, not to mention the cache coherency issues.

See also: Gold Blog, by Ian Lance Taylor. [although he uses <templates>]

Community
  • 1
  • 1
artless noise
  • 21,212
  • 6
  • 68
  • 105
  • An important point missed is relocations. Assemblers write object files where things are noted to be relocatable by a linker or loader. The concept of using the pre-processor is limited to PC-relative leaf functions (or code with no externals). – artless noise Jul 05 '19 at 15:45
  • Another book on the topic https://eli.thegreenplace.net/2010/01/25/book-review-linkers-loaders-by-john-levine – artless noise Jul 08 '22 at 22:17
3

What limitations would gcc have creating assembler [...] ?

A lot. There's a reason we use assemblers for assembling and C preprocessors for preprocessing.

Firstly, as you just just have shown it yourself, you can't use the normal assembler syntax be it in style Intel or AT&T. You have to use those ugly parentheses.

Second, those __attribute__ directives you're talking about have nothing to do with the preprocessor, it doesn't even recognize them. They're hints for the compiler, and the compiler will in turn produce assembly code guided by these attrbutes (or not).

Perhaps this is an XY problem

It is for sure.

I am trying to understand why there are so many assemblers at all.

For the same reason there are various types of programming languages, compilers, cars and clothes out there: one tool doesn't fit everyone's needs. People are different, they do different things with their toolchain, they find the one easier to use than the other (personally I'd use the GNU assembler if it didn't require the AT&T syntax, which I just can't support), etc.