Index
> Compiler Internals > Problems with labels in 1.71.08 and 1.71.09 beta releases.Goto page 1, 2 Next |
| Author |
|
|
MHajduk 01 Apr 2013, 21:23
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 
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. |
|||
01 Apr 2013, 21:23 |
|
|
MHajduk 01 Apr 2013, 23:14
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.  |
|||
|
01 Apr 2013, 23:14 |
|
|
l_inc 01 Apr 2013, 23:15
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 |
|||
|
01 Apr 2013, 23:15 |
|
|
Tomasz Grysztar 02 Apr 2013, 09:35
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.
|
|||
|
02 Apr 2013, 09:35 |
|
|
l_inc 02 Apr 2013, 11:13
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 |
|||
|
02 Apr 2013, 11:13 |
|
|
Tomasz Grysztar 02 Apr 2013, 11:33
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.
|
|||
|
02 Apr 2013, 11:33 |
|
|
l_inc 02 Apr 2013, 12:33
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 |
|||
|
02 Apr 2013, 12:33 |
|
|
hopcode 02 Apr 2013, 17:06
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...  could you provide us an example, please ?
Cheers,  _________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||
|
02 Apr 2013, 17:06 |
|
|
l_inc 02 Apr 2013, 19:15
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 |
|||
|
02 Apr 2013, 19:15 |
|
|
hopcode 02 Apr 2013, 19:48
is it not about macro+switching encodings ?
 _________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||
|
02 Apr 2013, 19:48 |
|
|
l_inc 02 Apr 2013, 22:41
hopcode
Well spotted! These two words do really appear in the topic.  _________________ Faith is a superposition of knowledge and fallacy |
|||
|
02 Apr 2013, 22:41 |
|
|
baldr 02 Apr 2013, 22:44
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:
|
|||
|
02 Apr 2013, 22:44 |
|
|
hopcode 03 Apr 2013, 04:53
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 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...
_________________ ⠓⠕⠏⠉⠕⠙⠑ |
||||||||||
|
03 Apr 2013, 04:53 |
|
|||||||||
|
Tomasz Grysztar 03 Apr 2013, 10:13
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). And so fasm itself did everything as expected here, that's why I stated that it is a bug in macro, which I corrected. |
|||
|
03 Apr 2013, 10:13 |
|
|
Tomasz Grysztar 03 Apr 2013, 12:15
l_inc wrote: Tomasz Grysztar |
|||
|
03 Apr 2013, 12:15 |
|
|
l_inc 03 Apr 2013, 13:53
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 |
|||
|
03 Apr 2013, 13:53 |
|
|
Tomasz Grysztar 03 Apr 2013, 14:01
l_inc wrote: Tomasz Grysztar 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. |
|||
|
03 Apr 2013, 14:01 |
|
|
l_inc 03 Apr 2013, 14:09
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".
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 |
|||
|
03 Apr 2013, 14:09 |
|
|
revolution 03 Apr 2013, 14:13
l_inc wrote:
Code: mov eax, resources.icons ;No problem resources: .strings: include 'strings.inc' resources.icons: include 'icons.inc' |
|||
|
03 Apr 2013, 14:13 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|