Index
> Compiler Internals > label vs virtual directive |
| 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? |
|||
30 Nov 2003, 10:01 |
|
|
BiDark
Thx.
|
|||
|
02 Dec 2003, 02:17 |
|
|
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. |
|||
|
02 Dec 2003, 09:14 |
|
|
vid
smart
but what about virtual at ebx? Can you also do "label name at ebx"? |
|||
|
02 Dec 2003, 10:33 |
|
|
Tomasz Grysztar
Yes. Why don't you just try?
 |
|||
|
02 Dec 2003, 11:33 |
|
|
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. |
|||
|
02 Dec 2003, 17:56 |
|
|
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 |
|||
|
02 Dec 2003, 19:05 |
|
|
vid
really thanks, by the way si it problem to do something like
+24 pointer to symbol name ???? |
|||
|
03 Dec 2003, 18:28 |
|
|
Tomasz Grysztar
The size of the structure would have to be changed.
|
|||
|
03 Dec 2003, 20:52 |
|
|
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. |
|||
|
04 Dec 2003, 05:03 |
|
|
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.
|
|||
|
04 Dec 2003, 10:02 |
|
|
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. |
|||
|
04 Dec 2003, 10:41 |
|
|
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. |
|||
|
04 Dec 2003, 10:50 |
|
< Last Thread | Next Thread > |
Forum Rules:
|