just an idea, but, in directives, can it be added a sector directive?
like a label, this one will bring the possibility to write disk images, sector by sector, and link them. like this:

this idea is not very clear in my mind, but i was many times limited by unexistance of this directive.

If it is not clear in your mind, how do you know what is the actual limitation and what do you expect from the directive?

The "sdd" is a part that I really don't understand what do you mean. As for "sector directive", do you just need to ensure that certain part of the source will start at a given sector? This could be done by "overloading" ORG so you keep track of the adjustments of $ and $$ and then the padding can be calculated correctly. If that was you mean I could write it for you if you want. (if someone know that there are simplier ideas to achieve this please tell).

[edit]Perhaps I will move this discussion from this thread later, all depends in how it evolves[/edit]

padding is not a problem for me
it's just that, when using many org statements in source, labels are always relative to the last org.
i just need a label global access, the real offset of the label. independant of the org.
this will permitt, as stated above, to directlly write DISK images and file systems.
i know there are the global and local directives, but i doubt it can be used for that.
sdd is for sector-define-dword, other names are possible, as:
chsd for CHS dword, or LBAd for a lba dword, etc...
these values will automatically be loader with the good sector number.

for exemple, in the boot sector, to address a sector, just give the name of a label into the desired sector.
then, preprocessor will give the exact location of the label in the linear assembled file or the sector number.

OK, lets call this "sdd" d{w|d}fo (define {word|dword} file offset). No need for "sector" directive at all then?

I vote for having a macro that return the calculated offset on an assembly-time variable so you can do whatever you want later. You would invoke it as "offsetToFileOffset yourLabelOrPlainOffset, res" then, "res" variable will have the calculated value. Of course this is great but it isn't doable I see no way to make it work with forward referencing.

Well, this request belong to compiler internals then. Do you agree in using "Feature request: label file offset directive (LFO)" as thread title?

If you will start deleting before I move this specific topic, please move this first, since it is doable from compiler side (rest some definitions on what to do when you don't pass a plain nor out of virtual block label, though).

i agree, in fact i've made an other mistake by putting the first post in general/fasm as a package for community

good choice for the title.

Done, I have used the word "operator" too since looks more reasonable to be an operator like RVA, PLT and so on.

RVA is for windows? no?
what is PLT?

what do you mean with Done?
you have the solution?

LFO is not a good idea for the directive name as it is the
Low Frequency Oscillator initials.
LFO is a label i'll use in the future for sound programming function.

I would try to formulate this more generally:

You want named address spaces, and ability to reference base of address space from other address spaces. I think this can (in most cases) be overcomed by existing features.

Example:

No, I've done the split with the title I originally suggested except that I added "operator" on it. Tomasz (or perhaps someone else but in such case would not be officially released) has to implement it.

About PLT, check it yourself http://flatassembler.net/docs.php?article=manual#2.4.4

And what I mean by operator is that in the same way you can do "relativeAddress dd RVA someLabel" also be able to do "fileAddress dd FO someLabel". I would have the same ways of using it as RVA, but instead of retrieving the virtual address it would give you the file offset (or error if cannot be retrieved).

vid, I think he wants this:


And if the number of bytes between the source beginning and l1 is 84, then fileOffset content will be 84.

it is exactlly what i want, and as FO is the initial for a frensh politic team, i agree with FO for this offset calculation.

Force Ouvriere
Travailleurs, Travailleuses .... votez pour moi! pffff mort de rire!