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, 9, 10  Next
Author
Thread Post new topic Reply to topic
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6602
Location: Kraków, Poland
A small update today adds few more built-in symbols. $@ is there to help count reserved data inside virtual blocks (because $%% only helped to measure it in the actual output areas). The __FILE__ and __LINE__ were added after shoorick's suggestion and they can be used to display where something was defined, generate debug info, or show a warning with a macro like:

Code:
macro warn msg*
        repeat 1 num:__LINE__
                display __FILE__,' [',`num,']',13,10
        end repeat
        display 'Warning: ',msg,'.',13,10
end macro

warn 'something is fishy here'



Last edited by Tomasz Grysztar on 05 Sep 2016, 17:34; edited 1 time in total
Post 05 Sep 2016, 08:34
View user's profile Send private message Visit poster's website Reply with quote
idle



Joined: 06 Jan 2011
Posts: 342
Location: ukraina
can that be applied to fasm?
Post 05 Sep 2016, 09:29
View user's profile Send private message Send e-mail Reply with quote
shoorick



Joined: 25 Feb 2005
Posts: 1575
Location: Ukraine
thanks!
Post 05 Sep 2016, 10:13
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


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

idle wrote:
can that be applied to fasm?

fasm's variables are only 65-bit and cannot hold an entire string, for this reason it is not possible to implement __FILE__ as a built-in assembler's variable like I did it in fasmg. I think it could work as a special kind of symbolic variable in preprocessor, but fasm's preprocessor currently does not have anything like that.
Post 05 Sep 2016, 11:51
View user's profile Send private message Visit poster's website Reply with quote
randall



Joined: 03 Dec 2011
Posts: 152
Location: Poland
Tomasz, would it be a good idea to implement AMD GCN3 instruction set using fasmg? (http://gpuopen.com/compute-product/amd-gcn3-isa-architecture-manual/)

Thanks
Post 09 Sep 2016, 13:30
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


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

randall wrote:
Tomasz, would it be a good idea to implement AMD GCN3 instruction set using fasmg? (http://gpuopen.com/compute-product/amd-gcn3-isa-architecture-manual/)

I think that it would be a good idea in case of every instruction set that is not implemented yet. As long as anyone is up to it, I encourage to give it a try.
Post 09 Sep 2016, 14:10
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6602
Location: Kraków, Poland
The new release (0.98) comes with a change to LOCAL directive functionality. I concluded that the added feature of locality prediction has found no real use, while it noticeably impacts performance of the assembler. Therefore I decided to simplify the function of LOCAL and now it is more similar to its namesake from fasm 1 - the symbol becomes local only in the part of macro that comes after the LOCAL directive has been used.
Post 11 Sep 2016, 21:21
View user's profile Send private message Visit poster's website Reply with quote
shoorick



Joined: 25 Feb 2005
Posts: 1575
Location: Ukraine
how about something kinda eof - just stop far reading the file?

it may be used for "includeonce" implementation:


Code:
if defined mmm
  eof
else
  restore mmm
  mmm = 1
end if



-- it can be better of course Wink
Post 12 Sep 2016, 08:05
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


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

shoorick wrote:
how about something kinda eof - just stop far reading the file?

You could perhaps make it with a trick like:

Code:
macro EOF?
        __FILE = __FILE__
        macro ?! line&
                if __FILE__ <> __FILE
                        purge ?
                end if
        end macro
end macro


However:

shoorick wrote:

Code:
if defined mmm
  eof
else
  restore mmm
  mmm = 1
end if


would give you a "missing END directive" error - if assembler skipped processing the rest of file it would never get to see the "end if". You'd need to work around it in some way:

Code:
if defined mmm
    macro execute
        eof
    end macro
else 
    macro execute
    end macro

    restore mmm
    mmm = 1
end if

execute

Post 12 Sep 2016, 09:17
View user's profile Send private message Visit poster's website Reply with quote
shoorick



Joined: 25 Feb 2005
Posts: 1575
Location: Ukraine
thanks, i'll try!

yes, i've been thinking about that missing of the "end if", as well as to use file name as the name of definition to not invent exclusive variable name for each file (to not mix/mess them), I just haven't figured out yet the better way to do that Rolling Eyes
Post 12 Sep 2016, 09:35
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: 15159
Location: GW170817
For OSes with case insensitive filenames there may be a problem when matching by the text name only. And for all OSes that have paths specifiers that can be relative (i.e. "..") then getting to the same file via a different path can also cause a problem. Can the assembler be modified to check for the unique file ID?

IMO for modular assembly "includeonce" type functionality is very important.
Post 12 Sep 2016, 10:03
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


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

revolution wrote:
For OSes with case insensitive filenames there may be a problem when matching by the text name only. And for all OSes that have paths specifiers that can be relative (i.e. "..") then getting to the same file via a different path can also cause a problem. Can the assembler be modified to check for the unique file ID?

I avoided such advanced filesystem functions in fasm and fasmg OS interface on purpose, to keep the porting simple.


revolution wrote:
IMO for modular assembly "includeonce" type functionality is very important.

I think that the "invented names" shoorick mentioned are in general better (from my point of view I'd say "more correct") method, because if you happen to have the same file (or different versions of the same headers) in different places, they are still going to detect this and act accordingly.


shoorick wrote:
(...) as well as to use file name as the name of definition (...)

Even though it has the potential vulnerabilities that revolution mentioned, this method still sounds interesting so you might want to try it out anyway. You could convert the special characters in file path in such a way that you would obtain a valid name for a variable. I tried it like this:

Code:
define files

macro includeonce? path*
        local str,name,char,cmd
        virtual at 0
                db path
            str:
                db 'symlink equ files.'
                repeat str
                        load char : byte from %-1
                        if (char >= '0' & char <= '9') | (char >= 'a' & char <= 'z') | (char >= 'A' & char <= 'Z') | char >= 80h
                                db char
                        else
                                db '@'
                                db 80h + char
                        end if
                end repeat
                db '?' ; for case-insensitive filesystems only (and it doesn't work for letters other than A-Z)
                load cmd : $ - str from str
        end virtual
        display cmd,13,10 ; just to see how macro works
        eval cmd
        if ~ defined symlink
                match variablesymlink
                        restore variable
                        variable = 1
                end match
                include path
        end if
end macro

This is an interesting hack, but in general I still think that it is better to arrange things in such a way that they do not depend on filesystem structures.
Post 12 Sep 2016, 12:34
View user's profile Send private message Visit poster's website Reply with quote
idle



Joined: 06 Jan 2011
Posts: 342
Location: ukraina
i suppose board.fasm.net & Board.Fasm.Net nonsense different?..
Post 12 Sep 2016, 14:26
View user's profile Send private message Send e-mail Reply with quote
shoorick



Joined: 25 Feb 2005
Posts: 1575
Location: Ukraine
I think just filename without path could be enough for a while... just if I already have included "math.inc" to not include it again.

in future, when fasmg set of includes will be bloat more than windows psdk, maybe more fine method will be required, but not now yet. Wink

generally, if we spend time to invent name for the file, we can invent name for the trap label, or even name it similar, but we can later guess the better name for the file and get the name mismatch, or make it temporal copy with "_" and include both: one explicitly into the source and other implicitly via some other include, which already includes it (against it exactly includeonce exists but fails here), and even file ID will may not save against such situation, but trap label may... or not... many situations can appear, it's not possible to prevent all of them by assembler itself...
Post 12 Sep 2016, 14:26
View user's profile Send private message Visit poster's website Reply with quote
idle



Joined: 06 Jan 2011
Posts: 342
Location: ukraina
shoorick, afaik, fasm(g) fetches full path/name of any file it processes
Post 12 Sep 2016, 14:30
View user's profile Send private message Send e-mail Reply with quote
shoorick



Joined: 25 Feb 2005
Posts: 1575
Location: Ukraine
yes, I see. but anyway two full paths of the same file, if not resolved, also may differ:

Code:

C:\spec\fasmg\fasmg.exe LL-2.asm LL-2.rks

flat assembler g  version 0.97.1471502275
C:\spec\winasm\..\lib85/spec.inc [25
Errorillegal instruction.

ERRORLEVEL2

-- it's a C:\spec\lib85/spec.inc sure Wink but, of course, it's an exotic situation Wink
Post 12 Sep 2016, 17:09
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2624
Location: dank orb
Given that the object file formats support multiple instruction sets. Doesn't it make more sense to have "format.inc" include the "x64.inc" et al. Actually, this might not be compatible with current FASM functionality? (Since one could use64 in a Win32 PE.)
Post 12 Sep 2016, 21:07
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


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

bitRAKE wrote:
Given that the object file formats support multiple instruction sets. Doesn't it make more sense to have "format.inc" include the "x64.inc" et al. Actually, this might not be compatible with current FASM functionality? (Since one could use64 in a Win32 PE.)

Not only that, but it would also hide the fact that with fasmg macro packages you can freely choose what instruction set extensions to include (though I have not implemented everything yet, I still need few days off to work on AVX etc.).

On the other hand, "format.inc" is just a simple example that provides a bit of familiar syntax for fasm users, so I think it would not really hurt to follow your suggestion. For full customizability you'd be better off using the macro packages directly anyway, as demonstrated by some of my samples in other threads.
Post 13 Sep 2016, 09:01
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2624
Location: dank orb
I'm having trouble understanding the scoping of symbols. I'd like to encapsulate the naming as much as possible, doing something like:

Code:
  ; generate Import Address Tables (IAT)
  namespace PE
    irpv lib,Libraries
      namespace lib
        align 8
        .IAT; Is the dot needed here?
        irpv fun,Functions
          fun dq RVA fun#_String
        end irpv
      end namespace
      rq 1
    end irpv
  end namespace

Yet, how can "ExitProcess" be defined outside of the namespaces? (Something I'd like to avoid - should only be PE.Kernel32.ExitProcess.) I've reread the namespace stuff in the manual too many times. Going to step back from it for a bit. I'm definitely missing something.
Post 14 Sep 2016, 21:11
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


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

bitRAKE wrote:

Code:
      namespace lib
        align 8
        .IAT; Is the dot needed here?


If you use "namespace" you should not use the dot. See the sample of "struct" macro in the manual - it uses the "namespace" block to get rid of the dots.


bitRAKE wrote:
I've reread the namespace stuff in the manual too many times. Going to step back from it for a bit. I'm definitely missing something.


Note that "namespace" by itself does not create a namespace. It only switches the focus and temporarily (until the "end namespace") changes the namespace you are working in. The argument to "namespace" is an identifier of a symbol and it is interpreted just as if it was used in an expression, as long as such symbol exists. If there is no defined symbol with given identifier, the (undefined) symbol in current namespace is used - but I recommend to always use "namespace" with a defined symbol.


Last edited by Tomasz Grysztar on 15 Sep 2016, 03:35; edited 1 time in total
Post 14 Sep 2016, 21:51
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, 9, 10  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.