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 Previous  1, 2
Author
Thread Post new topic Reply to topic
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
revolution
Again, the point is not to find a solution for this particular case, but to give a notion of general guidelines for writing safe headers and macros.

It is generally not good to define a global label in a general-purpose header.
It is generally not good to allow a macro to be called outside of it's intended context such as this one:
Code:
.else
mov eax,1
.endif    

It is generally not good to define a non-unique symbol inside of a header, which is not a part of the header's interface, such as defargs@proc (even considering the "@proc" notation).

All this produces side effects, which at some point result in complicated problems similar to this one.

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



Joined: 16 Jun 2003
Posts: 7802
Location: Kraków, Poland
Tomasz Grysztar
l_inc wrote:
It is generally not good to define a global label in a general-purpose header.
I think it is quite to the contrary - the usual function of a header file is to define some global symbols. If you have a header with lots of function imports, you most probably want all of them to be global labels. The Win32 headers define global structure symbols, etc. etc.


I still agreed, however, that making the encoding includes in such a way that they can be included from any place and any number of times, is a nice idea - and I made it that way.
Post 03 Apr 2013, 14: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
Tomasz Grysztar
Quote:
I think it is quite to the contrary - the usual function of a header file is to define some global symbols.

First of all, there's a crucial difference between the term "symbol" and the term "label".

Secondly, the key point is here the header's file interface, i.e. all the features the header file provides to it's user. If the purpose of the header file is to define global labels, it should define labels. But in the context of the cited statement such headers are not considered to be general-purpose. As I previously said, macros should generally avoid using anonymous labels, but this is obviously not applicable to this macro, as defining an anonymous label is it's exact functionality.

Thirdly, I suppose, we need to define the term "header file" in the context of fasm. The header files in fasm are used to be the files with the extension inc. How many of those are intended to define global labels without invocation of their macros? Thus I'd define a header file as a file, that produces no output (into the resulting compiled executable) as a standalone compilation unit. Therefore I still insist, that header files generally should not define non-unique global labels, whereby it's obviously not a problem to define a macro (as a part of the header's interface), which in turn does define global labels, such as the import macro, but only if this is it's intended functionality.

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



Joined: 16 Jun 2003
Posts: 7802
Location: Kraków, Poland
Tomasz Grysztar
l_inc wrote:
Tomasz Grysztar
Quote:
I think it is quite to the contrary - the usual function of a header file is to define some global symbols.

First of all, there's a crucial difference between the term "symbol" and the term "label".
Yes, the term "label" is specific to assembly language, and what I stated about headers is a bit more general.

l_inc wrote:
The header files in fasm are used to be the files with the extension inc.
Actually, for the headers I envisioned the .ASH extension, but I used it only in one place (ASMEDIT.ASH). The .INC extension is a generic one for an include file, which may be defined as a file that cannot be assembled by itself, but needs to be included in a actual project (which is based in file with .ASM extension).

l_inc wrote:
How many of those are intended to define global labels without invocation of their macros?
Well, the most standard header (not a macro package) would define some function imports (like with EXTRN directive) and data structures. That's what I had in mind when I said that the usual function of a header is to define a bunch of global symbols. Some of these symbols may be represented in fasm's case by labels, some not. But in this light the statement that headers by a rule should not define global labels sounds like absurd to me.

I would say that header, by its name, is something that needs to be included before the actual program/data. Thus the encoding includes in their new version are a more general kind of include rather than simply a header, because now they can be included from anywhere, and any number of times.
Post 03 Apr 2013, 15:59
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:
Yes, the term "label" is specific to assembly language, and what I stated about headers is a bit more general.

There are labels in different languages such as in C. But my statements here are all related to fasm only.
Quote:
The .INC extension is a generic one for an include file, which may be defined as a file that cannot be assembled by itself, but needs to be included in a actual project

The fasm documentation mentions only .inc-files as headers. And there's no problem to include .asm-files, which implies, that any (includable) file is an include file as soon as it's included. Thus I always thought, that "macro packages" are also headers.
Code:
Well, the most standard header (not a macro package) would define some function imports (like with EXTRN directive)    

What do you mean under "would"? If we are still talking about fasm, then there are no examples of standard fasm headers, that directly expose labels to external symbols, unless a corresponding macro is invoked? The standard fasm headers are just macro packages. If we were talking about C headers or macrodefinitions, I would definitely suggest completely different guidelines and also use different terminology.
Quote:
and data structures

Data structures are a completely different thing in fasm, as those are simulated with macros and therefore do not produce side effects per se. If global labels were not producing side effects, I also would never suggest to avoid including global labels into header files.
Quote:
I would say that header, by its name, is something that needs to be included before the actual program/data.

The terminology does not necessarily have to retain it's etymological meaning, even though this is mostly desirable. The problem with your definition is that due to the fasm's features, what actually has to be included before are the macro packages, because preprocessor symbols cannot be forward-referenced as opposed to the labels. Therefore the usual meaning of headers (where you forward-declare labels, because you can't forward-reference those) is not well applicable to fasm.

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



Joined: 16 Jun 2003
Posts: 7802
Location: Kraków, Poland
Tomasz Grysztar
l_inc wrote:
What do you mean under "would"? If we are still talking about fasm, then there are no examples of standard fasm headers, that directly expose labels to external symbols, unless a corresponding macro is invoked?
I did mean a headers for the purpose of being used with object output. Yes, there are no standard headers like that released for fasm, because fasm's packages only contain the includes for the purpose of standalone fasm programming.

With headers for direct executable output it became more problematic, since in fasm you have then to build import table yourself. But that's just a specific case.

l_inc wrote:
Data structures are a completely different thing in fasm, as those are simulated with macros and therefore do not produce side effects per se.
They have the same kind of side effect, because "struct" macro defines global labels (the structure field offsets).
Post 03 Apr 2013, 17: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
Quote:
They have the same kind of side effect, because "struct" macro defines global labels (the structure field offsets).

Oh. Sorry. My bad. This makes my argumentation invalid, as using current fasm's feature set the struct-related side effects are unavoidable without a trade-off.

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



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
well,well,well, i was so curious eh eh eh
the input:: is only in the utf8.inc. all other *.inc there, the macros and the manual too are yet free from that javadoc-feature!

1) the utf-8 du redefine should not output utf-16, in all cases, whether having Windows OS
or not; whether having an utf-8 text editor or not. reasons are not only for the difficoulty
it hides on place. example in the attached img
you are warned,developers Wink

2) switching encoding may be solved in design mode (considering global labels, as sugested aboveetc).
or alternatively, all the ENCODE\encodings macros in the .inc may be enabled/disabled/reenabled
at preprocessing time. advantage is they all already redefine du.

anyway, it is not needed getting rid of the javastyle-feature input::
Cheers,
Very Happy


Description:
Filesize: 4.78 KB
Viewed: 7471 Time(s)

utf8-dudef.png



_________________
⠓⠕⠏⠉⠕⠙⠑
Post 04 Apr 2013, 16:39
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 see, that you're still using non-unique non-interface symbols, i.e. __encoding . How about the following situation? I'm declaring some strings using one of the custom encodings and wanna restore the original encoding after that. As long as du is an interface symbol of the header, I'm going to do purge du + restruc du . But with your implementation this is not enough and I also should do restore __encoding . But (!) as a user of the headers I should not be aware of __encoding as it's not an interface symbol, i.e. it's not meant to be accessed by the user.

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



Joined: 16 Jun 2003
Posts: 7802
Location: Kraków, Poland
Tomasz Grysztar
You have no reason to know that all it does is redefining du - it affects all the other Win32 macros and how it does it is not stated. To switch encoding again you need to include another encoding file. You should know how are you going to encode the part of text that follows, of course.
Post 05 Apr 2013, 23:29
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:
how it does it is not stated

Seems like an artificial introduction of lack of feature. Smile "It is there, but don't use it".
Quote:
You should know how are you going to encode the part of text that follows, of course.

Which is kinda problem in some situations, because in most cases I'd like to cleanup after myself, rather than to define a new environment.

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



Joined: 16 Jun 2003
Posts: 7802
Location: Kraków, Poland
Tomasz Grysztar
l_inc wrote:
Tomasz Grysztar
Quote:
how it does it is not stated

Seems like an artificial introduction of lack of feature. Smile "It is there, but don't use it".
It is there just like a feature that you can switch a simple encoding by redefining the "_encoding" symbol. It is obvious when you read the sources of all the macros, but in you want to use only what is officially documented, then neither redefining "__encoding" directly nor redefining "du" is justified. The "TCHAR" or resource macros could work in a different way and not use "du" at all.

l_inc wrote:
Quote:
You should know how are you going to encode the part of text that follows, of course.

Which is kinda problem in some situations, because in most cases I'd like to cleanup after myself, rather than to define a new environment.
Being able to clean up and restore the encoding may be useful, but for this we would need to develop some new syntax. Currently all you have is including the encoding file that makes the Win32 macros work with such encoding from this place on.
Post 06 Apr 2013, 09:28
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 completely agree with all you say. Except probably the following statement:
Quote:
The "TCHAR" or resource macros could work in a different way and not use "du" at all.

TCHAR does not belong to the interface of the encoding files. Thus it either uses the only public interface du, or implements it's own translation, which would be a really bad idea, as it would highly reduce usefulness of the encoding headers. Same is true for the resource headers.

The overall point is that I just don't understand why you prefer
Code:
rept 1 { local ..encoding
         __encoding equ ..encoding }    

more than
Code:
rept 1 { local ..encoding
;here the [i]virtual[/i] block and the [i]du[/i] redefinition macro
}    

In the latter case you can avoid declaration of an additional symbolic constant. Furthermore this constant can potentially correlate with symbols from other (e.g. user defined) headers.

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



Joined: 16 Jun 2003
Posts: 7802
Location: Kraków, Poland
Tomasz Grysztar
l_inc wrote:
TCHAR does not belong to the interface of the encoding files.
The encoding files are part of the Windows programming headers set, and they were designed to work in this context. I had not intention to make them a separate and independent being.

l_inc wrote:
In the latter case you can avoid declaration of an additional symbolic constant. Furthermore this constant can potentially correlate with symbols from other (e.g. user defined) headers.
It is not a new thing for my macros to keep some settings in a global symbolic variable (like prologue@proc). Here it serves no purpose right now, but I like it this way.
Post 06 Apr 2013, 15:45
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 had not intention to make them a separate and independent being.

That's OK. But this does not necessarily prevent you from applying generally appreciated concepts such as modularization and intermodular interface simplicity and clarity.
Quote:
It is not a new thing for my macros to keep some settings in a global symbolic variable

Yes. And I hoped, you'll find it worth to reconsider this approach in favor of minimization of side effects.
Quote:
like prologue@proc

prologue@proc is a different thing, because it's a part of the customization interface of the procedure macros.
Quote:
but I like it this way

Unbeatable argumentation. Smile But nevertheless it's a valid argument.

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



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
and last but not least, the fact that up to 0x10000 - 1 converts simply to 2-byte scalar value doesnt offer any useful opportunity
but planning mess. one should work always on the input string considering eventually the output as "at-the-last-stage".

virtual,virtual,virtual prerpocessing, then the last stage, presumably the assembling one, you may think to output
what you like: scalar/utf-16/utf-8 etc. but fasm should be aware of that scalarizing virtual system.
yet better if that system could be embedded in fasm.

you are not able at the moment even to change encoding in the case you work on an already encoded evaluated stream,
and yet more problems arises obviously when the scalar goes beyond plane 0, when touching the output of one of those macro, as i
showed above.
neither renaming "utf8.inc" to "input_utf8_to_scalar" would be designedly-speaking correct.
solution is to keep du-output always virtual. tchar doesent matter. it may be an envelop to du
follows that those "encodings" should not be designed as "for Windows", as Tomasz said above

"heck, two digits are enough.. It's not as if anyone is gonna care" said Grace Hopper
when planning the Y2K bug. sorry cannot resist Laughing , i must post the photo of the bug ..ehhm of the Admiral... with goood intentions ehh, Smile

Image

Cheers,
Very Happy

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 07 Apr 2013, 14:08
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 Previous  1, 2

< 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. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.