NASM Forum > Programming with NASM
Error when using "istruc"
Frank Kotler:
The use of "istruc" is to initialize an instance of a struc. :)
The so-called local label ".byte" is "valid" from the previous non-local label ("str", in this case) to the next non-local label (there's a mechanism, "..@label" which is neither local nor non-local - it won't break the "scope" - I don't think it will help here)
Outside of this "scope", Nasm's local labels (unlike "true" local labels) can be referred to by its "full name" - "str.byte" in this case.
Within the "scope" begun by "label:", there is no local label ".byte", so "label.byte" won't work. Outside of the "scope", begun by "str" and ended by "label", the only name recognized is "str.byte" - and it's value is the offset of ".byte" from the beginning of the struc. So you need:
--- Code: ---mov al, [label + str.byte]
--- End code ---
Note that the C syntax "strucname.membername" does something completely different (the full address) from "strucname.localname", which is merely the "full name" of the member (and evaluates to zero, in this case) - you'll have to add the offset of the beginning of the struc to get the "full address". This applies even if you don't use local labels as the names of your members - but it looks less like the C syntax, which may reduce confusion.
If you observe that this makes using local labels as element names less useful than it might be, I'd agree, but that's "the way it works", and I don't think it's fixable without a complete rework of the local label mechanism... which I don't see happening.
This all may seem somewhat strange - especially if you're expecting C-like syntax - but it's a pretty "workable" mechanism, I find, once you get used to it (YMMV).
As to working "without macroses", "struc" *is* a macro, so good luck with that! :)
If you can think of how this might be more clearly documented - help us out!
Best,
Frank
Serge:
OK. Let it be the very strange syntax and behaviour. I still don't loose the hope to derive some degree of use from this construction. But my hope becomes less day by day.
I need to reserve space for future structures and i tried to declare "istruc" in .bss section. The code looks like following:
--- Code: ---struc mytype
.data: resb 1
endstruc
section .bss
mystruc:
istruc mytype
iend
--- End code ---
On compilation I get the following warning: attempt to initialize memory in a nobits section: ignored.
This warning is not covered by "-w" scope. So I can't disable it. Or can? Anyway just disabling the warning is not the best solution.
By the way. The documentation must be fixed because in paragraph 4.11.11 it is used exactly the form that will not compile:
--- Code: ---mystruc:
istruc mytype
at mt_long, dd 123456
at mt_word, dw 1024
at mt_byte, db 'x'
at mt_str, db 'hello, world', 13, 10, 0
iend
--- End code ---
--- Quote from: Frank Kotler on February 24, 2010, 05:04:40 PM ---If you can think of how this might be more clearly documented - help us out!
--- End quote ---
I'd be glad, but something tells me that the behaviour of this mechanism should be reworked before. I think that the best way is to move structures from "macro" to internal mechanism. This will open the broad way to enhance and to "polish" them.
Keith Kanios:
--- Quote from: Serge on February 27, 2010, 05:58:06 PM ---I need to reserve space for future structures and i tried to declare "istruc" in .bss section.
--- End quote ---
In there lies your problem. istruc is used to declare an instance of a structure. Trying to initialize data in a .bss (uninitialized data section) should fail with a warning at best.
Uninitialized or dynamic (runtime allocated) memory needs to utilize pointer references.
--- Quote from: Serge on February 27, 2010, 05:58:06 PM ---By the way. The documentation must be fixed because in paragraph 4.11.11 it is used exactly the form that will not compile:
--- Code: ---mystruc:
istruc mytype
at mt_long, dd 123456
at mt_word, dw 1024
at mt_byte, db 'x'
at mt_str, db 'hello, world', 13, 10, 0
iend
--- End code ---
--- End quote ---
I find that NASM does exactly what is documented in this case. The following "readable" code example demonstrates how to properly utilize initialized and uninitialized structs in NASM.
--- Code: ---struc mytype
mt_long: resd 1
mt_word: resw 1
mt_byte: resb 1
mt_str: resb 32
endstruc
[section .text]
;Access Initialized Struct
lea ebx,[mystruc]
mov eax,DWORD[ebx + mt_long]
mov cx,WORD[ebx + mt_word]
mov dl,BYTE[ebx + mt_byte]
lea esi,[ebx + mt_str]
;Populate Uninitialized Struct
lea ebx,[mystruc2]
mov DWORD[ebx + mt_long],eax
mov WORD[ebx + mt_word],cx
mov BYTE[ebx + mt_byte],dl
lea edi,[ebx + mt_str]
;Copy Initialized String to Uninitialized Struct
COPY:
mov bl,BYTE[esi]
cmp bl,0
je DONE
mov BYTE[edi],bl
inc esi
inc edi
jmp COPY
DONE:
ret
[section .data]
mystruc:
istruc mytype
at mt_long, dd 123456
at mt_word, dw 1024
at mt_byte, db 'x'
at mt_str, db 'hello, world', 13, 10, 0
iend
[section .bss]
mystruc2: RESB mytype_size
--- End code ---
You'll find that the way NASM implements structs may be more verbose, but I would expect no less access/control from an assembler. You can always use macros to abstract away if you need.
Serge:
Oh, yes, I'm so sorry... I didn't read these two sections carefully enough and didn't see the clue - '_size' suffix that allows to declare uninitialized structures. This is due to lack of experience with NASM.
Thank you for your patience. Went to try to code my task...
Keith Kanios:
--- Quote from: Serge on February 27, 2010, 10:44:48 PM ---Oh, yes, I'm so sorry... I didn't read these two sections carefully enough and didn't see the clue - '_size' suffix that allows to declare uninitialized structures. This is due to lack of experience with NASM.
Thank you for your patience. Went to try to code my task...
--- End quote ---
Well, I think that qualifies for Frank's "If you can think of how this might be more clearly documented - help us out!" statement :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version