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 |
|
JohnFound 13 Oct 2014, 23:29
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. |
|||
13 Oct 2014, 23:29 |
|
AsmGuru62 14 Oct 2014, 00:26
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. |
|||
14 Oct 2014, 00:26 |
|
revolution 14 Oct 2014, 03:17
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 |
|||
14 Oct 2014, 03:17 |
|
AsmGuru62 14 Oct 2014, 14:24
Prefixing - that is what I do too.
Actually, my FASM Writer IDE does it. |
|||
14 Oct 2014, 14:24 |
|
ejamesr 14 Oct 2014, 15:26
Prefixing with the file name (or namespace) certainly works, great suggestion!
|
|||
14 Oct 2014, 15:26 |
|
l_inc 15 Oct 2014, 11:22
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 |
|||
15 Oct 2014, 11:22 |
|
revolution 15 Oct 2014, 11:26
l_inc wrote: If one has multiple code libraries with equal names ... |
|||
15 Oct 2014, 11:26 |
|
l_inc 15 Oct 2014, 12:03
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 |
|||
15 Oct 2014, 12:03 |
|
revolution 15 Oct 2014, 12:08
l_inc wrote: File naming has nothing to do with collisions of labels defined in the file. 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), ... l_inc wrote: ... then also consider equally named files withing different folders of the same project. |
|||
15 Oct 2014, 12:08 |
|
Tomasz Grysztar 15 Oct 2014, 12:48
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.
|
|||
15 Oct 2014, 12:48 |
|
ejamesr 15 Oct 2014, 21:22
I can't wait for fasm 2!
Any hints as to a timeline? other features? |
|||
15 Oct 2014, 21:22 |
|
l_inc 15 Oct 2014, 23:21
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 |
|||
15 Oct 2014, 23:21 |
|
revolution 16 Oct 2014, 02:46
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? l_inc wrote:
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. 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 . l_inc wrote:
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. |
|||
16 Oct 2014, 02:46 |
|
Tomasz Grysztar 17 Oct 2014, 13:22
ejamesr wrote: I can't wait for fasm 2! 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.) |
|||
17 Oct 2014, 13:22 |
|
JohnFound 17 Oct 2014, 13:39
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. |
|||
17 Oct 2014, 13:39 |
|
l_inc 17 Oct 2014, 13:43
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 |
|||
17 Oct 2014, 13:43 |
|
revolution 17 Oct 2014, 17:24
Tomasz Grysztar wrote: ... the codename for current project to "gasm" |
|||
17 Oct 2014, 17:24 |
|
revolution 17 Oct 2014, 17:30
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. |
|||
17 Oct 2014, 17:30 |
|
Tomasz Grysztar 17 Oct 2014, 22:30
revolution wrote:
|
|||
17 Oct 2014, 22:30 |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.