flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > Any plans to add 'namespace' feature?

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



Joined: 04 Feb 2011
Posts: 52
Location: Provo, Utah, USA
ejamesr
Does anybody know how to imitate the 'namespace' feature of HLLs? And if not, I'd like to ask that this be added to the "suggested new features" list. I would like to do the following (which is becoming more of an issue as I create more and more source-code files that sometimes use the same names):
Code:
include "File1.Asm"
include "File2.Asm"
MyProc:
        call    Test1::proc1
        call    Test2::proc1
        ret
;..............
; Contents of File1.Asm...
namespace Test1 ; Create first namespace
proc1:
        mov     eax, [.var1]
        mov     ecx, [.var2]
        ret
.var1:  dw      45
.var2:  dw      9999
end namespace   ; or 'namespace' with no parameter closes the namespace
;........................

; Contents of File2.Asm...
namespace Test2 ; same global and .local labels, but different namespace
proc1:
        mov     eax, [.var1]
        mov     ecx, [.var2]
        ret
.var1:  dw      45
.var2:  dw      9999
end namespace
    

I don't know if multiple namespaces are needed. But if there was just a simple way to say, "Add this string to the front of every global label until I change the string", that would be very helpful.

Thank you for considering this... and please let me know if there's already a way to do this.

- ejamesr
Post 13 Oct 2014, 22:48
View user's profile Send private message Send e-mail Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
Well, FASM has global and local labels (two levels). You suggest one more level, so if implemented, there will be three. Then someone will suggest "supernamespace" in order to be four...

IMHO, if needed at all, it should be implemented as a general solution. Anyway, in most practical cases, such name spaces can be implemented in macros. For example you can define several nested structures and the labels will be a member of a tree with an arbitrary depth.
Post 13 Oct 2014, 23:29
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1398
Location: Toronto, Canada
AsmGuru62
Good idea, I think.
If you have a lot of some old code and you want to merge into bigger code base - there may be conflicts.
Because you have a certain style where you name things the same.
The namespace would solve this nicely.
Post 14 Oct 2014, 00:26
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16847
Location: In your JS exploiting you and your system
revolution
I often prefix my global labels with the uppercase filename:
Code:
;file ubergame.inc
proc UBERGAME_initialise ...

;file mega3D.inc
proc MEGA3D_initialise ...

;etc.    


Last edited by revolution on 14 Oct 2014, 16:16; edited 1 time in total
Post 14 Oct 2014, 03:17
View user's profile Send private message Visit poster's website Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1398
Location: Toronto, Canada
AsmGuru62
Prefixing - that is what I do too.
Actually, my FASM Writer IDE does it.
Post 14 Oct 2014, 14:24
View user's profile Send private message Send e-mail Reply with quote
ejamesr



Joined: 04 Feb 2011
Posts: 52
Location: Provo, Utah, USA
ejamesr
Prefixing with the file name (or namespace) certainly works, great suggestion!
Post 14 Oct 2014, 15:26
View user's profile Send private message Send e-mail Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
AsmGuru62 pointed out the essential advantage of namespaces. Everyone else including the TS missed the point. If one has multiple code libraries with equal names (no matter if the names are prefixed or not) and both need to be used in a project (e.g. a library implementing AVL trees and one implementing red-black trees), then there will be conflicts. I think this feature could be implemented by improving some standard macros such as proc. proc in fact lacks lots of useful features such as static variables (equally named globally stored but only locally available variables shouldn't conflict) or alignment of local variables.

_________________
Faith is a superposition of knowledge and fallacy
Post 15 Oct 2014, 11:22
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16847
Location: In your JS exploiting you and your system
revolution
l_inc wrote:
If one has multiple code libraries with equal names ...
There is your problem right there. Use a better file naming scheme and save yourself a lot of hassle.
Post 15 Oct 2014, 11:26
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
revolution
File naming has nothing to do with collisions of labels defined in the file. If you suggest to prepend each and every label defined in a file with the file name (which is quite a bad idea by itself), then also consider equally named files withing different folders of the same project.

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


Joined: 24 Aug 2004
Posts: 16847
Location: In your JS exploiting you and your system
revolution
l_inc wrote:
File naming has nothing to do with collisions of labels defined in the file.
I was aware.
l_inc wrote:
If you suggest to prepend each and every label defined in a file with the file name (which is quite a bad idea by itself), ...
Just the ones access globally i.e. not beginning with a dot (.). So why is it a bad idea?
l_inc wrote:
... then also consider equally named files withing different folders of the same project.
For your example of two different trees, then I would name them 'rb-tree' and 'avl-tree' (or similar). If you just name everything 'tree' and rely in the folder name to provide distinction then I think that is a bad idea.
Post 15 Oct 2014, 12:08
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7414
Location: Kraków, Poland
Tomasz Grysztar
I sometimes mentioned that actually dislike the NASM-inspired dot-based locals mechanism that fasm uses. It does not in fact integrate well with the rest of language. If I could get away with breaking the backward compatibility on this one, I would replace it with something that would blend better with other features (and would allow indefinite nesting). But I leave that for fasm 2, eventually.
Post 15 Oct 2014, 12:48
View user's profile Send private message Visit poster's website Reply with quote
ejamesr



Joined: 04 Feb 2011
Posts: 52
Location: Provo, Utah, USA
ejamesr
I can't wait for fasm 2!

Any hints as to a timeline? other features?
Post 15 Oct 2014, 21:22
View user's profile Send private message Send e-mail Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
revolution
Quote:
Just the ones access globally i.e. not beginning with a dot

Meaning that a file with a set of constant definitions such as HKEY_CLASSES_ROOT, FILE_ATTRIBUTE_NORMAL etc. should rather name all the constants like kernel32_HKEY_CLASSES_ROOT, kernel32_FILE_ATTRIBUTE_NORMAL... Did I understand you correctly?
Quote:
So why is it a bad idea?

One reason is in the previous paragraph. For another one, just look at the file names suggested by you for the trees. Those cannot become a part of an identifier. Aside from that, file names should be verbose with respect to a general concept within them. This verbosity might become too excessive for the specific names in it. Like if you look at the Windows kernel code, you'll see the convention of naming functions prepended with only two or three letters standing for a subsystem like MmIsAddressValid (where Mm stands for memory manager) located in the file pagfault.c .

Quote:
For your example of two different trees, then I would name them 'rb-tree' and 'avl-tree'

That's because you already know there would be both in a single project. But if you didn't, you'd probably name both bintree independently and then you'd be confronted by a naming conflict. The point is that you can't be sure for the whole unforeseeable future, that your prefix will never create collisions with any other library you'll ever be using.

_________________
Faith is a superposition of knowledge and fallacy
Post 15 Oct 2014, 23:21
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16847
Location: In your JS exploiting you and your system
revolution
l_inc wrote:
Meaning that a file with a set of constant definitions such as HKEY_CLASSES_ROOT, FILE_ATTRIBUTE_NORMAL etc. should rather name all the constants like kernel32_HKEY_CLASSES_ROOT, kernel32_FILE_ATTRIBUTE_NORMAL... Did I understand you correctly?
Not really. Those are predefined outside of our control. But in the general sense I don't see your reasoning here.
l_inc wrote:
Quote:
So why is it a bad idea?

One reason is in the previous paragraph.
You will need to be more explicit here. You example above does not give a reason. It expects me to see something inherently wrong that I don't see.
l_inc wrote:
For another one, just look at the file names suggested by you for the trees. Those cannot become a part of an identifier.
Why? In fact I have a red-black tree implementation and all global functions are named RBTREE_...
l_inc wrote:
Aside from that, file names should be verbose with respect to a general concept within them. This verbosity might become too excessive for the specific names in it. Like if you look at the Windows kernel code, you'll see the convention of naming functions prepended with only two or three letters standing for a subsystem like MmIsAddressValid (where Mm stands for memory manager) located in the file pagfault.c .
Sure, as long as they show the intention and are specific to the task. We don't need to be stupid and put 50 character prefixes.
l_inc wrote:
Quote:
For your example of two different trees, then I would name them 'rb-tree' and 'avl-tree'

That's because you already know there would be both in a single project. But if you didn't, you'd probably name both bintree independently and then you'd be confronted by a naming conflict.
No. That is because I know these things get used in different ways and using generic uninformative names like bintree gets me in trouble too often.
l_inc wrote:
The point is that you can't be sure for the whole unforeseeable future, that your prefix will never create collisions with any other library you'll ever be using.
True, I can't (and don't) know the future. But I was suggesting a workaround/solution, I wasn't saying it is the one and only answer to all the problems.
Post 16 Oct 2014, 02:46
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7414
Location: Kraków, Poland
Tomasz Grysztar
ejamesr wrote:
I can't wait for fasm 2!

Any hints as to a timeline? other features?
For a long time I've been almost overwhelmed by my own ideas. But little by little I get the most important design blocks figured out, and I think I may soon be ready to start actually writing something. Very Happy

At this moment I've changed the codename for current project to "gasm", as in "generic assembler", because the most challenging and interesting parts of my design are not related to a specific machine code like x86, and I plan this initial project to have no code generator module at all. The only instructions that would produce any output would be DB/DW/DD/etc. One would be able to implement some simple instruction sets using the macro engine, just like it's been done many times with fasm 1.x already - and it could actually be an interesting tool by itself. Later, depending on how well the gasm architecture would be received, it could become a base for fasm 2 (and perhaps fasmarm 2, etc.)
Post 17 Oct 2014, 13:22
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
The "G" prefix is actually monopolized by the GNU project and to use it for not GNU projects is IMHO not good idea. (In addition, "gasm" resembles "gas" that is just a parody of assembler...)

Of course, for temporary use as a project code name it is OK, but renaming later might be not easy.
Post 17 Oct 2014, 13:39
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
revolution
Quote:
Those are predefined outside of our control. But in the general sense I don't see your reasoning here.

The reasoning is exactly what you are saying: there are predefined things outside of your control, and those things might cause collisions solvable with namespaces.
Quote:
It expects me to see something inherently wrong that I don't see.

You are absolutely right here.
Quote:
Why? In fact I have a red-black tree implementation and all global functions are named RBTREE_

But not rb-tree, right? The point here is that if you say "file naming scheme" and from your point of view this expression automatically and unambiguously implies naming scheme of the global symbols inside the file, then I assume it should be understood literally: every single character of the file name must become a prefix of every globally visible symbol. And this is a bad idea, because file naming has OS-imposed restrictions different to the symbol naming restrictions imposed by fasm.
Quote:
Sure, as long as they show the intention and are specific to the task. We don't need to be stupid and put 50 character prefixes.

This was exactly my point when I said that it was a bad idea.
Quote:
But I was suggesting a workaround/solution, I wasn't saying it is the one and only answer to all the problems

Well, then I probably misunderstood you, cause "There is your problem right there. Use a better file naming scheme" sounded for me like a general solution to the naming collisions a was talking in my post before.

P.S. In fact I didn't want to argue for namespaces, because it seems, that the concept by itself would violate the existing clear separation between the preprocessor and the assembler. I assume it's obvious that preventing the preprocessor identifier collisions is not less important than preventing assembly-time identifier collisions.

_________________
Faith is a superposition of knowledge and fallacy
Post 17 Oct 2014, 13:43
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16847
Location: In your JS exploiting you and your system
revolution
Tomasz Grysztar wrote:
... the codename for current project to "gasm"
So should be we using fasm orgasm? Razz
Post 17 Oct 2014, 17:24
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16847
Location: In your JS exploiting you and your system
revolution
l_inc wrote:
The point here is that if you say "file naming scheme" and from your point of view this expression automatically and unambiguously implies naming scheme of the global symbols inside the file, then I assume it should be understood literally: every single character of the file name must become a prefix of every globally visible symbol. And this is a bad idea, because file naming has OS-imposed restrictions different to the symbol naming restrictions imposed by fasm.
Well I wasn't speaking in absolute terms. One can use whatever naming scheme they choose. As long as it is reasonable, logical and concise then things should go smoothly for the most part. If exceptional circumstances arise then sobeit, we failed. But a good scheme will minimise failures and make it easy to recover when it does. Pobodies nerfect.
Post 17 Oct 2014, 17:30
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7414
Location: Kraków, Poland
Tomasz Grysztar
revolution wrote:
Tomasz Grysztar wrote:
... the codename for current project to "gasm"
So should be we using fasm orgasm? Razz
I thought that could just be a different variant of incrementation... instead of increasing 1 of 2 it would increment "f" to "g". But after the fact I realized that it could bring this association (funny, how it reminds me of Betov's SpAsm). Well, the name (especially codename) is not that important at the moment. It may as well be "fasm g" or something.
Post 17 Oct 2014, 22:30
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-2019, Tomasz Grysztar.

Powered by rwasa.