flat assembler
Message board for the users of flat assembler.
![]() Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 Next |
Author |
|
jacobly 04 Feb 2016, 18:54
In fasmg case-insensitive symbols declared with namespace can't be accessed without ?.
Code: namespace a? b? = 'A' end namespace display a.b Code: flat assembler g version 0.97.1452724235 error.asm [4] Error: symbol 'b' is undefined or out of scope. |
|||
![]() |
|
Tomasz Grysztar 04 Feb 2016, 19:14
I recommend to always declare a namespace related to a defined symbol, like:
Code: a? = 1 namespace a? Code: define a? ; comment this out to change the result namespace a b? = 'a' end namespace namespace a? b? = 'A' end namespace display a.b, a?.b Any identifier containing dots is processed step by step, that is: it first looks for a symbol defined by "a" (and when no such symbol is defined it uses the namespace of such case-sensitive name in current namespace) and only when it is decided what namespace it is, it starts looking for "b" symbol in that namespace. If you do not define a symbol that namespace refers to, you can get into trouble even when using only case-sensitive symbols everywhere. For example: Code: namespace a b = 'a' end namespace namespace other display a.b ; error, because "a" is not defined anywhere and this identifier defaults to "other.a.b" end namespace |
|||
![]() |
|
shoorick 17 Feb 2016, 08:06
just a thought a while: "postpone" keyword is very convenient to "envelope" output, but if there are more than one level, it would be good to execute postpones in reverse order... of course, there can be other different cases...
just a wish: it would be good to have a "-d" commandline switch to define something to have some control of assembling outside of the source. and I'll remind my pink wish which became blue many years ago: I would like the "file" directive were looking for the file similar to "include" directive: in %INCLUDE% folders also ![]() sure, I do not insist on them, just maybe to put into "todo" list (or into list "nottodo" ![]() |
|||
![]() |
|
Tomasz Grysztar 09 Apr 2016, 20:58
I am again working on the basic package, since I would like to finally make the 1.0 release, but I still feel I should add a few more things. I have written an introductory documentation in addition to the manual, it tries to explain what fasm g is and how can it be used.
I have also been encouraged by the successful self-hosting of fasm g and I may try to create even larger set of macros for x86 and x86-64 architectures, possibly supporting all the instruction sets and formats that fasm 1 supports. But this could take still much more time to finish. |
|||
![]() |
|
rugxulo 11 Apr 2016, 22:13
I briefly looked at the intro, it seems nice enough. It seems to end almost too abruptly, but I assume this was just a quick attempt.
I have no complaints, only two small suggestions: add more blank lines to separate sections, and avoid (accidental?) hard tabs. |
|||
![]() |
|
Tomasz Grysztar 12 Apr 2016, 16:31
rugxulo wrote: I briefly looked at the intro, it seems nice enough. It seems to end almost too abruptly, but I assume this was just a quick attempt. |
|||
![]() |
|
Tomasz Grysztar 19 Apr 2016, 18:11
Even though the documents still need a lot of work, I converted them to HTML and added to the Documentation section, so that they may start being indexed. They are also more accessible this way.
|
|||
![]() |
|
Tomasz Grysztar 23 Apr 2016, 20:47
I'm slowly adding new paragraphs to the introductory text. I'm planning to write another section about the output formats, in particular how to generate relocations like the ELF object formatting macros do.
|
|||
![]() |
|
Tomasz Grysztar 12 May 2016, 15:48
Today I found time to write some additional x86 instruction set macros, this time up to P6 MMX. I plan to add SSE and then x64 with 64-bit output formats. The macros are easy to write and it would be nice to have them able to assemble all the instructions and formats that fasm 1 can (turning a blind eye to the performance), so I think I'm going to keep adding them.
|
|||
![]() |
|
revolution 13 May 2016, 00:40
I notice that you have hard coded the data sizes for x86 coding. This makes it awkward to program for other architectures where the data sizes are not the same as x86.
e.g. "word", and the associated "dw"/"rw", need to be 32-bits for ARM. And "hword"/"dh"/"rh" are non-existent. Is it expected that the users will modify the fasmg sources to customise the executable? |
|||
![]() |
|
Tomasz Grysztar 13 May 2016, 06:49
Continuing a long fasm's tradition, the new engine allows to re-define almost everything with macros etc. So when you implement all instruction sets through macros (and that is the focus of fasm g, which is not much more than the bare engine) you can also customize any keywords that get in the way.
The repository of fasm g contains a converted example for DCPU-16 architecture (I did not include it in the release package, because DCPU-16 is apparently dead) where even the "$" symbol is re-defined to have 16-bit granularity instead of usual 8-bit (I could do the same in the AVR example, but there the PC symbol serves the role). As for the customizing the executable, I had in mind that the new engine could also serve as a base for constructing the targeted assemblers. I even planned to make some kind of "assembler construction kit" for that purpose, and I'm going to work on it when I finally get bored with the macro play. Some of the customizations would still need a better tools to be added (or at least a good documentation of the use cases of fasm g internal API), but the data sizes are quite easy to customize already. For example, you could add directives DXX and RXX for the definitions of 128-bit data size and call it XXWORD, all just by adding the following definitions to the main symbol table: Code: SIZE_XXWORD = 128 db 3,'dxx',SYMCLASS_INSTRUCTION,VALTYPE_NATIVE_COMMAND,VAL_INTERNAL,SIZE_XXWORD dd define_data db 3,'dxx',SYMCLASS_STRUCTURE,VALTYPE_NATIVE_COMMAND,VAL_INTERNAL,SIZE_XXWORD dd define_labeled_data db 3,'rxx',SYMCLASS_INSTRUCTION,VALTYPE_NATIVE_COMMAND,VAL_INTERNAL,SIZE_XXWORD dd reserve_data db 3,'rxx',SYMCLASS_STRUCTURE,VALTYPE_NATIVE_COMMAND,VAL_INTERNAL,SIZE_XXWORD dd reserve_labeled_data db 6,'xxword',SYMCLASS_EXPRESSION,VALTYPE_PLAIN,VAL_INTERNAL,0 dd SIZE_XXWORD |
|||
![]() |
|
Tomasz Grysztar 16 May 2016, 17:25
shoorick wrote: just a thought a while: "postpone" keyword is very convenient to "envelope" output, but if there are more than one level, it would be good to execute postpones in reverse order... of course, there can be other different cases... |
|||
![]() |
|
Tomasz Grysztar 17 May 2016, 16:55
Another update according to plan, this time with SSE and SSE2 macros added. I also have the basic x64 macros ready, but I'm not putting them into the official package until I have more.
|
|||
![]() |
|
Tomasz Grysztar 20 May 2016, 14:47
x64 macros are ready, my old long mode examples assembled the same as with fasm 1. I also adjusted the PE.INC so that it supports PE+ and included the simplest Win64 example in the basic fasm g package.
I could keep going and add the remaining instruction sets and formats, but I think that would take too much of my free time right now. I may get back to writing auxiliary documentation etc. |
|||
![]() |
|
revolution 21 May 2016, 06:07
If there was a tool that could convert the macros to native code and integrate/link it with the parser this could make a really useful utility. Perhaps even become cross platform or something. That would really just be making another HLL, but no matter, there is always room for yet another HLL. In essence a compiler to compile the compiler.
In IMO the reason it may become necessary to convert it to native code is to reduce the compile time. Being able to compile and have the debugger running in just a few moments is a massive win when developing code. And having to wait many seconds, to many tens-of-seconds, for the compiler can become distracting and the train of thought becomes muddy. Sorry for the mixed metaphors |
|||
![]() |
|
Tomasz Grysztar 21 May 2016, 08:46
revolution wrote: If there was a tool that could convert the macros to native code and integrate/link it with the parser this could make a really useful utility. Perhaps even become cross platform or something. That would really just be making another HLL, but no matter, there is always room for yet another HLL. In essence a compiler to compile the compiler. |
|||
![]() |
|
shoorick 01 Jul 2016, 06:07
it's a same old story
![]() i try to avoid macro duplication. those two: Code: if ~ defined proc macro proc name name: if used name end macro macro endp! end if .end: end macro display "proc is defined",13,10 end if and Code: if ~ used proc_is_already_defined macro proc name name: if used name end macro macro endp! end if .end: end macro proc_is_already_defined = 1 display "proc is defined",13,10 end if simly do not work, and that variant gives an error (too many passes): Code: if ~ defined proc_is_already_defined macro proc name name: if used name end macro macro endp! end if .end: end macro proc_is_already_defined = 1 display "proc is defined",13,10 end if +++++++++++ this also do not work: Code: if ~ defined proc | defined proc_is_already_defined ... _________________ UNICODE forever! |
|||
![]() |
|
Tomasz Grysztar 01 Jul 2016, 08:22
You have the problem in applying the solution to the classic problem because the "defined" operator only works with symbols of the expression class. Here you have a symbol called "proc" of instruction class, but there is not symbol called "proc" of expression class. You can have both defined at the same time (or just one of them) and the "defined" operator only tests the availability of the expression-class symbol.
You can add the definition of expression-class symbol with the same name and then check for its availability (you can also use a different name for that symbol, like you already tried). The circular logic in condition can be avoided by making sure that symbol is a variable (the symbols that are re-defined cannot be forward-referenced), you can for example force this with "restore" directive: Code: if ~ defined proc_v restore proc_v ; this ensures that symbol cannot be forward-referenced proc_v = 1 macro proc name name: if used name end macro macro endp! end if .end: end macro display "proc is defined",13,10 end if If you used "proc" variable name instead of "proc_v", the "proc = 1" line would not work correctly because it would call the macro (fasmg allows macros to be forward-referenced, using the same rules as for the expression-class symbols). You could use "define" directive to prevent this from happening: Code: if ~ defined proc restore proc define proc 1 macro proc name name: if used name end macro macro endp! end if .end: end macro display "proc is defined",13,10 end if |
|||
![]() |
|
shoorick 01 Jul 2016, 09:22
Tomasz Grysztar wrote:
this works! thanks! _________________ UNICODE forever! |
|||
![]() |
|
Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.