[mod] complete restore

Index > Compiler Internals > [mod] complete restore

Author

Thread

idle

Joined: 06 Jan 2011
Posts: 439
Location: Ukraine

idle 08 Oct 2014, 13:26

Code:

;
;Hi.
;I have a file of next contents:
;

;re-defining MUCH times i.e. a one has no count
eq1 equ ...
eq2 equ ...
... 
eq1 equ ...
eq2 equ ...
...

;next label definition produce error if there is no CORRECT count
;restore eq1,eq1,eq2,eq2
eq1: 
eq2:

;could fasm introduce:
complete restore eq1, eq2

;thanks

08 Oct 2014, 13:26

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8268
Location: Kraków, Poland

Tomasz Grysztar 08 Oct 2014, 13:31

Code:

macro complete_restore [name] {
  irpv v,name \{ restore name \}
}

Works with fasm 1.71.18+.

PS Yes, I forgot to add something about this new directive into official manual. I need to correct this ASAP.

08 Oct 2014, 13:31

idle

Joined: 06 Jan 2011
Posts: 439
Location: Ukraine

idle 08 Oct 2014, 14:04

Thank you much.
What does "v" mean in your exaple?

08 Oct 2014, 14:04

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8268
Location: Kraków, Poland

Tomasz Grysztar 08 Oct 2014, 14:33

It is a name of parameter that iterates through all the values of symbolic variable. In this case it is not used, because for the RESTORE directive only the name of variable (not its value) is needed.

08 Oct 2014, 14:33

l_inc

Joined: 23 Oct 2009
Posts: 881

l_inc 08 Oct 2014, 15:33

Tomasz Grysztar
Is the nx flag in PE worth mentioning as well? And I think the documentation is a bit misleading about the addressing space labels, cause their limitation is not about being unable to reference a not yet assembled addressing space, but rather about not being able to forward-reference addressing space labels at all.

_________________
Faith is a superposition of knowledge and fallacy

08 Oct 2014, 15:33

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8268
Location: Kraków, Poland

Tomasz Grysztar 08 Oct 2014, 16:00

l_inc wrote:

Tomasz GrysztarAnd I think the documentation is a bit misleading about the addressing space labels, cause their limitation is not about being unable to reference a not yet assembled addressing space, but rather about not being able to forward-reference addressing space labels at all.

I have left this additional limitation as undefined, because I was not sure whether it is going to stay this way. My intention was to make that paragraph more about the general language specification than about the current implementation. Perhaps I should create a separate document discussing the limitations of current implementation that are not imposed on it by the language design.

08 Oct 2014, 16:00

l_inc

Joined: 23 Oct 2009
Posts: 881

l_inc 08 Oct 2014, 19:33

Tomasz Grysztar

Quote:

was not sure whether it is going to stay this way

That was actually my assumption. Btw. I didn't encounter any cases where current behaviour would be noticeably disadvantageous. Improving on forward referencing would certainly make the architecture look more solid, but practical importance is not obvious for me.

Quote:

Perhaps I should create a separate document discussing the limitations of current implementation that are not imposed on it by the language design.

This could be just an appendix in the main manual, so that it would be easy to cross-reference related pieces of information. Like

Quote:

... and assembler signalizes an overflow error if because of its limitations it is not table to perform the required calculation (see Appendix 2 for current implementation)

_________________
Faith is a superposition of knowledge and fallacy

08 Oct 2014, 19:33

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum