#"include" directives

16 messages · Page 1 of 1 (latest)

grave imp
#

I know overhauls for the assembler are planned, but one that I'd like to see if it isn't already planned is "include" directives. (that's the best name I could make up for them off my head)

An include directive looks for another program in the assembly editor window with the name that matches whatever is provided in the argument, and replaces the "include" directive with the binary of that program.

So, something like libraries, but in assembler. Pretty sure that's a feature in most assemblers, and especially in high level languages. In fact, IIRC, when you write something like #include <stdio.h> in c, it essentially represents that same instruction in assembly.

summer plume
#

To my knowledge, few if not no assemblers have this - you usually assemble files separately and then link them

idle salmon
#

if you write #include in C it represents that same instruction in assembly

No. Like, not at all in any meaningful way. This is something done by the C preprocessor, it doesn't get anywhere close to code generation

grave imp
sudden tangle
#

Including a header file produces the same results as copying the header file into each source file that needs it.
https://gcc.gnu.org/onlinedocs/cpp/Header-Files.html#Header-Files
it wouldn't make sense to copy binary, but it does make some sense to copy un-processed code before processing it (which will, for example, affect which numbers the labels point to)

tawny canopy
#

the trouble with includes in assembly is that it would change all your line numbers, which breaks all of your jump/branch instructions.. that can be worked around with a smart enough assembler but that just leaves you with debugging problems (which may or may not be an issue in TC depending on how tightly coupled the assembler code and the final running program are.. if they're coupled enough then the running program might still be able to maintain references to the original code file & line numbers across includes)

#

linking is the "proper" way to share code across assembler files.. its more like imports in Java than it is includes in C (though of course still not exactly the same hence having its own name 😄 )..

summer plume
#

including a header in C still requires you to link the implementation of that header

tawny canopy
#

depends whats in the header. C's preprocessor directives are a bit "special" by modern standards lol

earnest trout
#

Well *.h files in C\C++ for the most part but not always are declarations where the *.c, *.cpp etc... are your definitions. The precompiler and compiler sorts out all of the directives, macros, and declarations into symbols within the AST. It is then the Linker's Job to find all of the symbols - names to combine them. Some assemblers don't have a direct "include" or "import" a far as I know, but many of them do possess an "extern" feature. And many compilers support the ability to make and use function calls through the use of extern. Such as:

demo.asm

`global main
extern printf, scanf

Section .text

main:
push rbp
mov rbp, rsp
sub rsp, 16

xor eax, eax
lea rdi, [msg]
call printf ;invokes C's printf

mov eax, 0
lea rdi, [format]
lea rsi, [number]
call scanf ;invokes C's scanf

mov DWORD[rbp-4], 0

loop:
mov edx, [number]
mov, rsi, [rb4-4]
lea, rdi, [msg2]
xor eax, eax
call printf ; invokes C's printf

mov ecx, DWORD  [number]
add DWORD [rbp-4], 1

cmp[rbp-4], ecx
jle loop

add rsp, 16
leave
ret

Section .data
msg: db "Enter a number: ",0
msg2: db "Looping %d of %d, 10, 0
format: db "%d", 0

Section .bss
number resb 4`

earnest trout
#

Yeah i don't see "include" or "import" being a feature of an assembler. However, what would be nice to see, is the ability to "reference" from one program into another. In other words, if I define a label as a function foo in program1, It would be nice to be able to reference that label - function within program2 say where function bar can call foo. Behind the scenes, this shouldn't affect the assembler. This should be more on the "linker" side of things. During the parsing of the program, all you would need is a directive section that doesn't become "executable code" kind of like having a comment, yet when it sees the "directive such as: .extern anything between .extern and .code doesn't become binary or instructions but are hints as to other programs you'd be using. This way if you have something like this:

program1.asm

`.extern
program2 # the actual filename of program 2, 3, ... respectively
program3 # this section doesn't get compiled into binary or opcodes...
# just turns into a "lookup tabel"

.code

your assembly code here.

label foo
#x,y,z...
call bar
ret`

program2.asm

label bar # foo operation here ret

This could be very powerful even with small 256 byte programs. What this will do is look for the address of that function / label that address will get loaded into the binary, however, it won't be the same address as in the program that is calling it. And when you're debugging or watching the code run in the source editor, it would also be pretty cool for it to automatically switch to that program file when it jumps to that instruction. All you would need in the linker is a very good hash table with nearly no collisions. Or a BSP tree that keeps track of which "file" each address belongs to. Now this would be a cool feature!

sudden tangle
#

ah, wait, you mean just attaching different programs to each other

clever cedar
#

For this request, the game can simply concatenate the code and process the result

peak citrus
#

The most useful case I can think of for #include that won't break stuff is to include a common set of const definitions. However, I haven't hit a case yet where I had enough to warrant needing such a feature as they are more often than not level specific.

tawny canopy
#

maybe not in levels, but in sandbox absolutely.. think like, controlling a 7seg display for example, or implementing puts() to draw text to the console.. that sort of thing would be very handy to have in a shared library of some sort.. of course it would still only be useful within a single architecture but lots of people build general purpose archis and may write more than one program for them