flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Programming Language Design > On my new assembler

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
Author
Thread Post new topic Reply to topic
shoorick



Joined: 25 Feb 2005
Posts: 1563
Location: Ukraine
there is no any extra tool Wink it is better to have some extra than miss anyone Wink
i'm also not sure, but i saw avr projects realizing digital filtering of signals: they use integer arithmetic, which is descent from the float. somebody might wish to see calculated intermediate constants in such kind of projects in float representation Cool
Post 02 Dec 2015, 19:38
View user's profile Send private message Visit poster's website Reply with quote
jacobly



Joined: 04 Feb 2016
Posts: 2
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
Errorsymbol 'b' is undefined or out of scope.

Changing a to a? works correctly.
Post 04 Feb 2016, 18:54
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6303
Location: Kraków, Poland
I recommend to always declare a namespace related to a defined symbol, like:

Code:
a? = 1
namespace a?

because identifier like "a.b" looks for a defined symbol that "a" part applies to, and when no such symbol is found it defaults to the namespace of case-sensitive symbol in current context. You can check it with this kind of code:

Code:
define a? ; comment this out to change the result
namespace a
        b? = 'a'
end namespace
namespace a?
        b? = 'A'
end namespace
display a.ba?.b

Note that in this example the "namespace a" actually refers to the same namespace as "namespace a?", because "namespace" also looks for the defined symbol that matches "a", and only when no defined symbol is found it chooses the default case-sensitive one.

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

If you add a line defining global "a" symbol to the above example, it is going to work properly.
Post 04 Feb 2016, 19:14
View user's profile Send private message Visit poster's website Reply with quote
shoorick



Joined: 25 Feb 2005
Posts: 1563
Location: Ukraine
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 Rolling Eyes

sure, I do not insist on them, just maybe to put into "todo" list (or into list "nottodo" Very Happy )
Post 17 Feb 2016, 08:06
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6303
Location: Kraków, Poland
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.
Post 09 Apr 2016, 20:58
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2109
Location: Usono (aka, USA)
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.
Post 11 Apr 2016, 22:13
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6303
Location: Kraków, Poland

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.

Yes, I wanted to write more but I need to lay it out in my head first. Thank you for the feedback!
Post 12 Apr 2016, 16:31
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6303
Location: Kraków, Poland
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.
Post 19 Apr 2016, 18:11
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6303
Location: Kraków, Poland
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.
Post 23 Apr 2016, 20:47
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6303
Location: Kraków, Poland
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.
Post 12 May 2016, 15:48
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: 14672
Location: Origae-6
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?
Post 13 May 2016, 00:40
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6303
Location: Kraków, Poland
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

Post 13 May 2016, 06:49
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6303
Location: Kraków, Poland

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...

I have initially made it work the same as in fasm 1, but after giving it more thought I decided to change it to reverse order. I think you were right that this would be more appropriate.
Post 16 May 2016, 17:25
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6303
Location: Kraków, Poland
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.
Post 17 May 2016, 16:55
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6303
Location: Kraków, Poland
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.
Post 20 May 2016, 14:47
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: 14672
Location: Origae-6
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
Post 21 May 2016, 06:07
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6303
Location: Kraków, Poland

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.

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

I still think that the native implementation (fasm 2) would be necessary for good performance. I also considered making some kind of scripting language that could be compiled automatically into native instruction handlers, this is what I had in mind for an "assembler construction kit". But it would be a bit different language, more focused on this specific purpose. The macro language of fasm g is very ill-suited for compilation. On the other hand, it is probably possible to design some scripting of instruction encodings that could be converted into final native implementation with fasm g macros themselves, that could be kind of fun. But it all would still require quite a lot of work.
Post 21 May 2016, 08:46
View user's profile Send private message Visit poster's website Reply with quote
shoorick



Joined: 25 Feb 2005
Posts: 1563
Location: Ukraine
it's a same old story Smile

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!
Post 01 Jul 2016, 06:07
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6303
Location: Kraków, Poland
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

Because the variable in this example is a symbolic value, it is replaced with its value before evaluating the "if" - but the result is simply "if defined 1" and this condition is true. The "defined" operator only checks if the sub-expression that follows does not contain a symbol that is undefined. It even has an additional feature that it allows an empty sub-expression to follow, and since an empty expression does not contain any undefined symbols, the condition is true then. Therefore instead of "define proc 1" you could even use plain "define proc" (which gives the symbol an empty value) and this would still work correctly.
Post 01 Jul 2016, 08:22
View user's profile Send private message Visit poster's website Reply with quote
shoorick



Joined: 25 Feb 2005
Posts: 1563
Location: Ukraine

Tomasz Grysztar wrote:

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



this works! thanks!

_________________
UNICODE forever!
Post 01 Jul 2016, 09:22
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, 3, 4, 5, 6, 7, 8  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


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.