flat assembler
Message board for the users of flat assembler.
![]() |
Author |
|
BiDark
which is consumes more cpu time to finish the job (when the labels is fit in range). for example
Code: label a dword at ... and virtual at ... a dd ? end virtual which one? |
|||
![]() |
|
BiDark
Thx.
|
|||
![]() |
|
Tomasz Grysztar
"virtual" itself only changes the addressings for the following code, as it would the "org" do, and code is assembled normally until the "end virtual" is reached - then assembler moves code generation pointer back to the state at which it was when the "virtual" block was started - so it data will be overwritten by the new, real code.
And "load" directive allows you to load from addresses from what I called "current addressing space", that is from the area beginning at the last addressings change, like "org", "virtual", "section", etc. |
|||
![]() |
|
vid
smart
![]() but what about virtual at ebx? Can you also do "label name at ebx"? |
|||
![]() |
|
Tomasz Grysztar
Yes. Why don't you just try?
![]() |
|||
![]() |
|
vid
it is easier to ask, you know...
![]() i am just curious how you made it. I can imagine you can remember offset for each label - of course - but how can you remember value like 4*ebx + eax + 3? I just find it quite more dificult, so i wasnt sure. |
|||
![]() |
|
Tomasz Grysztar
OK, perhaps you'll have to wait long for it to be covered in the official fasm internals documentation, so here is a little gift - the structure of fasm's symbol entry (this is the 24-byte data structure used commonly for all labels, numerical constants and segments):
Code: Offset Size Description +0 qword value of symbol (signed) +8 word flags, any combination of the following values: 1 - symbol was defined 2 - symbol can be redefined (set only for symbols defined with "=") 4 - symbol was redefined (when set, no forward references to this symbol are allowed) 8 - symbol was used 10h - symbol was checked for being used with prediction in current pass 20h - result of last predicted check for being used 40h - symbol was checked for being defined with prediction in current pass 80h - result of last predicted check for being defined +10 byte size of data labelled by this symbol +11 byte type of symbol, any of the following values: 0 - absolute value 1 - relocatable segment address (only with MZ output) 2 - relocatable 32-bit address 3 - relocatable relative 32-bit address (only valid for symbol that is used in the same section where it was calculated, so it should not occur in the regular label structure) +12 dword extended SIB, first two bytes are register codes and second two bytes are corresponding scales +16 word number of pass in which symbol was defined last time +18 word number of pass in which symbol was used last time +20 dword address of object section or external symbol to which this symbol is relative (only for relocatable symbols with object output) This is the most actual data for the 1.50 release. Last edited by Tomasz Grysztar on 04 Dec 2003, 10:27; edited 2 times in total |
|||
![]() |
|
vid
really thanks, by the way si it problem to do something like
+24 pointer to symbol name ???? |
|||
![]() |
|
Tomasz Grysztar
The size of the structure would have to be changed.
|
|||
![]() |
|
JohnFound
Hi Privalov.
I have a question about label data. On which stage this data is created and what fields of it are filled initially? Regards. |
|||
![]() |
|
Tomasz Grysztar
Parser allocates addresses for those structures, and those addresses become the IDs for the labels (parser put the appropriate ID for each label into the fasm code, so assembler doesn't have to deal with names anymore). At this stage the memory that is reserved for them is used for other purposes, but parser only allocates the address. The 24-byte blocks are allocated from the top of main memory block, and assembler, before starting the first pass, fills all that area with zeros.
|
|||
![]() |
|
JohnFound
Thank you Privalov.
Another question: Is there some reference to the char name of the label, maybe not in this table but in preprocessed/parsed code? Regards. |
|||
![]() |
|
Tomasz Grysztar
At the parser stage the table of labels consists of 8-byte records, each containing the address of name string and the hash for label. When parser finds a record in this table that corresponds to the label for which ID it has to retrieve, it calculates the offset in table and multiplies it by 3, so the offset in the table of 24-byte records is obtained - and it makes an ID being the address of the 24-byte structure in table, which at assembly time replaces the old table of 8-byte records. Smaller record size is used at parser stage, because it makes hash scanning faster with data cache.
As the same memory is used for both tables, those references are of course lost at the assembly stage. |
|||
![]() |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.