flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > Problems with labels in 1.71.08 and 1.71.09 beta releases.

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
MHajduk



Joined: 30 Mar 2006
Posts: 6034
Location: Poland
MHajduk
A question to Tomasz Grysztar.

A few people reported already some problems with labels in 1.71.08 and 1.71.09 beta releases when tried to compile this code: http://board.flatassembler.net/topic.php?t=15278&start=0

Image

I'd like to emphasize that there are no problems when the same code is compiled with the latest stable release i.e. 1.70.03.
Post 01 Apr 2013, 21:23
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7715
Location: Kraków, Poland
Tomasz Grysztar
It is a bug in the new version of UTF8.INC - if you replace "input" with "..input" everywhere in that include, the bug will disappear. I will upload the corrected version soon.
Post 01 Apr 2013, 22:24
View user's profile Send private message Visit poster's website Reply with quote
MHajduk



Joined: 30 Mar 2006
Posts: 6034
Location: Poland
MHajduk
Tomasz Grysztar wrote:
It is a bug in the new version of UTF8.INC - if you replace "input" with "..input" everywhere in that include, the bug will disappear. I will upload the corrected version soon.
Thanks, this explains everything and allows me to regain a peace of mind. Wink
Post 01 Apr 2013, 23:14
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
Tomasz Grysztar
This update made me notice, that you are preventing usage of different encodings within the same project by using non-unique addressing space labels __encoding . And I also think, that it makes sense to start those with double dot. Not just because it can be desirable to change encoding somewhere in the middle of the source, but also as a matter of a good coding style.

_________________
Faith is a superposition of knowledge and fallacy
Post 01 Apr 2013, 23:15
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7715
Location: Kraków, Poland
Tomasz Grysztar
It's an interesting thought. I never considered the possibilty of having few different encodings in one file, as I know no editors that would support such thing - nonetheless it is still possible. So you're right that it would be nice and elegant to make the macros in such a way that they would allow that kind of usage.
Post 02 Apr 2013, 09:35
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
Tomasz Grysztar
Quote:
I never considered the possibilty of having few different encodings in one file

It does not necessarily have to be one file. There could be multiple data files with strings for different localizations.

_________________
Faith is a superposition of knowledge and fallacy
Post 02 Apr 2013, 11:13
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7715
Location: Kraków, Poland
Tomasz Grysztar
For multiple files it would be enough to allow including multiple headers in one project - but what I had in mind is a case when you switch encodings locally, as that is when it would be nice for it to use double dot prefix. Like if you have some inline strings in MessageBox invocations and switch encoding just before each one, inside a single procedure.
Post 02 Apr 2013, 11:33
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
Tomasz Grysztar
That's one possible use case, but single dot labels usage is not limited to procedures. E.g. you could include multiple localization files while defining a string resource directory and at the same time use local labels relative to the beginning of the resource section.

Anyway disregarding all the possible use cases the safe way is to follow the principle of minimization of side effects, which in this context implies using unique names for assembly time variables, prepending labels with double dot, avoiding anonymous labels, restoring/purging preprocessor constants and macros after using them (unless those belong to the interface of the corresponding header file), etc. Btw. there are some (AFAIK unsolvable) related problems such as creation of a single-shot macro without side effects or creation of co-macros without side effects.

_________________
Faith is a superposition of knowledge and fallacy
Post 02 Apr 2013, 12:33
View user's profile Send private message Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
1) Tomasz "...different encodings in one file, as I know no editors that would support such thing...
Cocoa port of scintilla manages different encodings. it is unuseful to apply it at a source level of scintilla.
but switching encoding in an HTML page is always possible. the information is in the HTML.
what you see is rendering. for this reason i think they will not apply in scintilla this switching feature.
in few words: it is the Cocoa capability to program scintilla, storing information on encodings.
as for example, discussion http://scintillanet.codeplex.com/discussions/348953

2) l_inc ...There could be multiple data files with strings for different localizations....
encodings have nothing to do with localizazions, unless you are rolling the old ANSI wheel.
but just because it is only by chance that fasm compile utf-8 source files, while you apply
your codepage in the quoted strings usually, trying to support the old wrecked ANSI wheel
in the code of fasm should be excluded a-priori. a homemade macro suffices.

3) Tomasz ...a case when you switch encodings locally...
ok, again, please: it may be done via-macro and last but not least you have already invented the :: virtual addressing capability.

4) Tomasz ...as that is when it would be nice for it to use double dot prefix...
Question could you provide us an example, please ?

Cheers,
Very Happy

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 02 Apr 2013, 17:06
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
hopcode
Sorry, none of your comments fits into the topic. It seems, that you just randomly chose phrases without trying to understand the corresponding context.

_________________
Faith is a superposition of knowledge and fallacy
Post 02 Apr 2013, 19:15
View user's profile Send private message Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
is it not about macro+switching encodings ? Laughing

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 02 Apr 2013, 19:48
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
hopcode
Well spotted! These two words do really appear in the topic. Smile

_________________
Faith is a superposition of knowledge and fallacy
Post 02 Apr 2013, 22:41
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
hopcode,

Original problem, stated in OP, is related to fasm feature: global label in virtual block affects attachment of local labels defined after corresponding end virtual. Probably Tomasz will add some save/restore code to change this behavior, for now it's better to use local (or not-so-global) labels inside virtual blocks that may be inserted by macro. Moreover, it isn't specific to latest 1.71.x branch: stable 1.70.03 behaves similar (heh, even 1.0 does that).

Problem occured because:
  1. since 1.71.01 du macro in ENCODING\UTF8.INC uses new method of translation, employing global addressing space label;
  2. extended invoke in WIN32WX.INC uses du (via pushd) to define literal string in-place, hence unexpectedly breaking local labels' attachment.
Neither macros nor encodings are directly related to that. I'm not saying that your comments/suggestions are worthless, though.
Post 02 Apr 2013, 22:44
View user's profile Send private message Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
that is exactly! from the practical point of view. i compiled OP code ok using old macros+1.71.09. i was sure it was UTF8.inc but i had no time to dig in it, also what i state is here http://board.flatassembler.net/topic.php?p=156234#156234
baldr Neither macros nor encodings are directly related to that ? No, indeed they are. what i state is a matter of coherence, again, and you know it Wink codepage is ANSI, but du is actually IMO only half-featured, just because it zeroes high byte, while replaceable from the dw in all cases.
i asked simple practical example from Tomasz, because encoding switching may be done via macro without any of the new features of 1.70 or 1.71. and without du too
i suggested/encouraged Tomasz to solve it at a macro level, as i read he would do in this case. featuring a du directive without macros involves a complete unicode rewrite of fasm.
and this is not the case. but to make it plain, i stated it
Quote:
3) Tomasz ...a case when you switch encodings locally...
ok, again, please: it may be done via-macro and last but not least you have already invented the :: virtual addressing capability.


Description:
Filesize: 9.16 KB
Viewed: 10627 Time(s)

3-1-9.png



_________________
⠓⠕⠏⠉⠕⠙⠑
Post 03 Apr 2013, 04:53
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7715
Location: Kraków, Poland
Tomasz Grysztar
baldr wrote:
Original problem, stated in OP, is related to fasm feature: global label in virtual block affects attachment of local labels defined after corresponding end virtual. Probably Tomasz will add some save/restore code to change this behavior, for now it's better to use local (or not-so-global) labels inside virtual blocks that may be inserted by macro. Moreover, it isn't specific to latest 1.71.x branch: stable 1.70.03 behaves similar (heh, even 1.0 does that).
It was always this way and will not be changed, because this NASM-mimicking local labels mechanism operates on preprocessed source level, so all the prefixing is done before assembly stage, and it cannot be aware of the later state at which this part of code will be assembled. You could put a few VIRTUAL directives in IF block and then a lot of END VIRTUAL inside other IF blocks and it may not be possible to know which ones will get executed until the actual assembly is performed.

And so fasm itself did everything as expected here, that's why I stated that it is a bug in macro, which I corrected.
Post 03 Apr 2013, 10:13
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7715
Location: Kraków, Poland
Tomasz Grysztar
l_inc wrote:
Tomasz Grysztar
That's one possible use case, but single dot labels usage is not limited to procedures. E.g. you could include multiple localization files while defining a string resource directory and at the same time use local labels relative to the beginning of the resource section.
Yes, that's possible in principle, but when I thought about it earlier, I hastily dismissed this option because I thought that it should not be encouraged to split name prefixing context across multiple files. But on the second thought - when you feel confident and know what you're doing, then you are free to do it this way. And I agree it would be nice if headers did their work right even in such exotic cases.
Post 03 Apr 2013, 12:15
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
Tomasz Grysztar
I feel like I'm being continuously misunderstood and should provide a simple code example:
Code:
mov eax, resources.icons   ;oops. undefined symbol, because strings.inc was saucy enough to define a global label

resources:
.strings: include 'strings.inc'
.icons: include 'icons.inc'    

As it can be seen, name prefixing is not split across multiple files.

_________________
Faith is a superposition of knowledge and fallacy
Post 03 Apr 2013, 13:53
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7715
Location: Kraków, Poland
Tomasz Grysztar
l_inc wrote:
Tomasz Grysztar
I feel like I'm being continuously misunderstood and should provide a simple code example:
Code:
mov eax, resources.icons   ;oops. undefined symbol, because strings.inc was saucy enough to define a global label

resources:
.strings: include 'strings.inc'
.icons: include 'icons.inc'    

As it can be seen, name prefixing is not split across multiple files.

It is - all the files here share the "resource" label space. If you define any label in the "strings.inc" file you have to keep that in mind (otherwise you may break ".icons" label definition by changing the prefix context). This is a fragile configuration and that's why I initially thought that it should not be encouraged. But still, it is a completely valid and allowed way of using fasm's features.
Post 03 Apr 2013, 14:01
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
Tomasz Grysztar
Quote:
It is - all the files here share the "resource" label space.

OK. Then it was an inconsistency in our definitions of "splitting across multiple files". Smile
Quote:
If you define any label in the "strings.inc" file you have to keep that in mind

The point is that it's not me, who defines the label, because strings.inc may just include one of the standard encoding headers. But you probably already considered that.

_________________
Faith is a superposition of knowledge and fallacy
Post 03 Apr 2013, 14:09
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17252
Location: In your JS exploiting you and your system
revolution
l_inc wrote:
Code:
mov eax, resources.icons   ;oops. undefined symbol, because strings.inc was saucy enough to define a global label

resources:
.strings: include 'strings.inc'
.icons: include 'icons.inc'    
If you know you could get yourself in trouble with an included file then you can do something like this:
Code:
mov eax, resources.icons   ;No problem

resources:
.strings: include 'strings.inc'
resources.icons: include 'icons.inc'    
Post 03 Apr 2013, 14:13
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< 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


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.