flat assembler
Message board for the users of flat assembler.

flat assembler > Programming Language Design > On my new assembler

Goto page Previous  1, 2, 3 ... 5, 6, 7 ... 9, 10, 11  Next
Author
Thread Post new topic Reply to topic
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6871
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: 351
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: 1603
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: 6871
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: 153
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: 6871
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: 6871
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: 1603
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: 6871
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: 1603
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: 15870
Location: 162173 Ryugu
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: 6871
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 variable, symlink 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: 351
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: 1603
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: 351
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: 1603
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] Error: illegal instruction. ERRORLEVEL: 2
-- 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: 2653
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: 6871
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: 2653
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: 6871
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 ... 5, 6, 7 ... 9, 10, 11  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 © 2004-2018, Tomasz Grysztar.

Powered by rwasa.