Inclusion directives in ASM

[Jarvix]

I propose the use of two new directives for ASM:

.include "<file>" .incbin "<file>"

where is a relative path from the source file. The include directive directly includes the content of the file on its location. the file should contain sourcecode. The incbin includes binary code: this is used after compiling the ASM. I am not sure how this would work out. Probably only with a label in front:

myImage: .incbin "myImage.bin"

I already implemented .include in my own assembler and it works great. Very useful when we have libraries and shared code.

[tpwrules]

These make sense. On "just using a label", insert it into the instruction stream as if it was a string define. Also, perhaps have a version where the high byte is 0 and one where bytes are packed. On Apr 6, 2012, at 8:34 PM, Jos Kuijpers wrote:

I propose the use of two new directives for ASM:

.include "<file>" .incbin "<file>"

where is a relative path from the source file. The include directive directly includes the content of the file on its location. the file should contain sourcecode. The incbin includes binary code: this is used after compiling the ASM. I am not sure how this would work out. Probably only with a label in front:

myImage: .incbin "myImage.bin"

I already implemented .include in my own assembler and it works great. Very useful when we have libraries and shared code.

---

Reply to this email directly or view it on GitHub: https://github.com/0x10cStandardsCommittee/0x10c-Standards/issues/4

[ghost]

This is nice. I'm in favour of at least the first one.

[kksym]

The issue I have with this is that it should be assembler-dependent what the inclusion directives are, I don't believe assemblers should have to adhere to a specific standard for inclusion syntax, as long as they perhaps have a way of including other files (This could be optional also in exceptional cases).

When you look at assemblers like FASM and NASM, they have their own syntactical ways of doing these sorts of things but they're interoperable because the semantics are effectively identical for file/binary inclusions. I think we would be better off just clarifying how inclusions should be done.

[ghost]

@kk surely it would be preferable for all assembly programmers for all the assemblers to do it that same way, wouldn't it?

[kksym]

@vorrac what you have to remember is that not all assemblers are normal assemblers like notch's, there are a fair amount of assembler DSLs embedded in languages like Lisp, Scheme and Ruby that won't permit that exact syntax.

What I think we should define the exact mechanics of is how a binary file is included (But not the inclusion syntax), so that any binary file assembled/compiled through any means that is compliant to the ABI can be included in any other assembly file without fear of breakage. Upon revision of what I previously said, I think source file inclusion should be completely up to the assembler to define the semantics and syntax of, as there would be no point universalising a syntax when assembly sources for differing assemblers will be fundamentally different anyway (Hence incompatible). This would mean that all assembler-agnostic libraries would be used through binary inclusion, although projects using the same assembler throughout could use a provided file inclusion feature if it is preferable.

[guelfey]

My problem with binary inclusion is that all labels are lost / converted to constant addresses (until wee agree on a standart for object files). Thus, you can't just include it in your program because all addresses will be wrong. So, if we want compability

• we either have to develop some kind of object file where the labels aren't lost
• or we have to do like you said earlier: clarify, how source code inclusions should be done.

(Please correct my if anything of the above is wrong).

[kksym]

@guelfey so standardising some form of linkable object format could perhaps be necessary? I still see problem with standardised source file inclusions due to the differences between assemblers, while standardisation of some sort of linkable binary format could be the better way forward for assembler-agnostic libraries.

[Jarvix]

I will be working on standardization of preprocessor directives, looking at both need, usablity and Notch-code. (http://pastebin.com/aJSkRMyC)

[enkore]

This issue is superseded by 0xSCA... plz close