flat assembler
Message board for the users of flat assembler.

Index > Main > flat assembler 1.71.00-01

Goto page Previous  1, 2, 3, 4
Author
Thread Post new topic Reply to topic
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 25 Sep 2012, 00:13
shutdownall wrote:
Where did you define if symbol is allowed in address expression ?
Some flag inside tables.inc ??
The register type is encoded in the high nibble. See "symbol_value:" in EXPRPARS.INC to follow the decoding of the table entries.
Code:
symbols_2:
;...
 db 'ax',10h,20h ; <--- 20h is the value for decoding the addressing    
Post 25 Sep 2012, 00:13
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 25 Sep 2012, 08:12
shutdownall wrote:
Where did you define if symbol is allowed in address expression ?
Some flag inside tables.inc ??
It's that piece of code that determines it, it does not use any data structures.
Post 25 Sep 2012, 08:12
View user's profile Send private message Visit poster's website Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 517
Location: Munich
shutdownall 25 Sep 2012, 11:59
revolution wrote:
The register type is encoded in the high nibble. See "symbol_value:" in EXPRPARS.INC to follow the decoding of the table entries.
Code:
symbols_2:
;...
 db 'ax',10h,20h ; <--- 20h is the value for decoding the addressing    


Are you sure ? Shocked

Seems like 10h is the value for address register because this is the same value for all registers ...

Code:
symbols_2:
 db 'ah',10h,04h
 db 'al',10h,10h
 db 'ax',10h,20h
 db 'bh',10h,07h
 db 'bl',10h,13h
 db 'bp',10h,25h
 db 'bx',10h,23h
 db 'ch',10h,05h
 db 'cl',10h,11h
 db 'cs',10h,62h
 db 'cx',10h,21h
 db 'dh',10h,06h
 db 'di',10h,27h
 db 'dl',10h,12h
 db 'ds',10h,64h
 db 'dx',10h,22h
 db 'es',10h,61h
 db 'fs',10h,65h
 db 'gs',10h,66h
 db 'ms',1Ch,41h
 db 'mz',18h,20h
 db 'nx',1Bh,83h
 db 'pe',18h,30h
 db 'r8',10h,88h
 db 'r9',10h,89h
 db 'si',10h,26h
 db 'sp',10h,24h
 db 'ss',10h,63h
 db 'st',10h,0A0h
    
Post 25 Sep 2012, 11:59
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 25 Sep 2012, 12:16
shutdownall wrote:
revolution wrote:
The register type is encoded in the high nibble. See "symbol_value:" in EXPRPARS.INC to follow the decoding of the table entries.
Code:
symbols_2:
;...
 db 'ax',10h,20h ; <--- 20h is the value for decoding the addressing    


Are you sure ? Shocked

Seems like 10h is the value for address register because this is the same value for all registers ...
Yes, I am sure. The second value is the one to look at. Not all registers in x86 can be used as address registers. You can't use CL as an address register.
Post 25 Sep 2012, 12:16
View user's profile Send private message Visit poster's website Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 517
Location: Munich
shutdownall 25 Sep 2012, 12:48
revolution wrote:
Yes, I am sure. The second value is the one to look at. Not all registers in x86 can be used as address registers. You can't use CL as an address register.


That would mean that ax is the only register which could be used as an address register. Shocked

Ah okay - it is just the high nibble.
Okay - I will keep a look at it.
Post 25 Sep 2012, 12:48
View user's profile Send private message Send e-mail Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 25 Sep 2012, 13:09
revolution
Quote:
You can't use CL as an address register.

Actually, ax, cx, dx also cannot be used as address registers. And I'm pretty sure, that the same is true for mz Smile.
Post 25 Sep 2012, 13:09
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 25 Sep 2012, 13:18
shutdownall wrote:
Ah okay - it is just the high nibble.
Okay - I will keep a look at it.
Well it is slightly more than that. You have to look at the code I pointed you to:
Quote:
See "symbol_value:" in EXPRPARS.INC to follow the decoding of the table entries.
Post 25 Sep 2012, 13:18
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: 20363
Location: In your JS exploiting you and your system
revolution 25 Sep 2012, 13:20
l_inc wrote:
revolution
Quote:
You can't use CL as an address register.

Actually, ax, cx, dx also cannot be used as address registers. And I'm pretty sure, that the same is true for mz Smile.
MZ is not listed as a base register with 10h as an identifier so the type/value in the second data column has a different meaning.
Post 25 Sep 2012, 13:20
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 25 Sep 2012, 13:32
revolution
mz was more a kind of a joke. But you didn't comment the other ones.
Post 25 Sep 2012, 13:32
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 25 Sep 2012, 13:32
shutdownall wrote:
That would mean that ax is the only register which could be used as an address register.
In case it wasn't clear, the example I posted was to show how you can identify address registers. The value 20h decodes as not-an-address-register.

When all else fails, read the source.
Post 25 Sep 2012, 13:32
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 25 Sep 2012, 13:36
revolution
Quote:
When all else fails, read the source.

OK. Disregard my last. I've just been compensating the lack of real communication. Rolling Eyes
Post 25 Sep 2012, 13:36
View user's profile Send private message Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode 25 Sep 2012, 13:38
revolution wrote:
In case it wasn't clear, the example I posted was to show how you can identify address registers. The value 20h decodes as not-an-address-register.
When all else fails, read the source.
there's no need reading it. you are explaining it, very well.
+1 from me to your extradimensional patience Very Happy
Cheers,

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 25 Sep 2012, 13:38
View user's profile Send private message Visit poster's website Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 517
Location: Munich
shutdownall 30 Sep 2012, 00:26
Tomasz Grysztar wrote:
shutdownall wrote:
Where did you define if symbol is allowed in address expression ?
Some flag inside tables.inc ??
It's that piece of code that determines it, it does not use any data structures.


Thank you Tomasz.

So first piece of work is done. Cool
Assemble instructions for Z80 are now ported to 1.71.01
Will do some small mods made for older Z80 code with labels without semicolon (have an autolabel directive developped) and integrate the listing function before posting the new version here.

Well about the code, it was simply a "comparison array" for address registers, a more or less endless function of "if this than that". Added two register values simply to this function.

Second was a bit tricky.
FASM was ending when assembling relative jump instructions.
Or let's better say crashing. Not nice to track.

Had to integrate
Code:
  mov     ebp,[addressing_space]    

into function calculate jump offset.
The following call to
Code:
     call    calculate_relative_offset    

let the code die when ebp not set correctly.

This was the only critical part because this function was simply copied from x86_64.inc.

But thinking of some new features - do you think there might be some more dependencies which should be proved ? Just a question - I think you have more about this stuff in your mind than me.

Thanks. Wink
Answers from revolution are appreciated in the same way as he did for ARM. Wink
Post 30 Sep 2012, 00:26
View user's profile Send private message Send e-mail Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 08 Oct 2012, 05:15
Tomasz Grysztar
A think one more bug is still present. Regarding negative addressing space bases. Negative bases are useful, but the base of the org directive is now handled differently compared to previous versions and to the virtual directive:
Code:
org -1
jmp $; was valid in older versions, but not anymore    
Post 08 Oct 2012, 05:15
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 08 Oct 2012, 06:42
You are right, this got messed up, I prepared a right value prepared in a register but then used zero instead of it. Embarassed

It should be OK now (1.71.04).
Post 08 Oct 2012, 06:42
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 08 Oct 2012, 16:38
Tomasz Grysztar
Your bugfixes are always so fast. You might never be sleeping.
Post 08 Oct 2012, 16:38
View user's profile Send private message Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 517
Location: Munich
shutdownall 28 Aug 2013, 23:54
Tomasz Grysztar wrote:
shutdownall wrote:
Well - looks good for my codeblock directive planned for my ZX81 Basic version. Mixxing Z80 assembler code with ZX81 Basic instructions. Wink
When we discussed this problem it was one of the moments in recent times when I thought "again! if only I had this feature". The fact that I considered it so important that I included it in the list of highlights for fasm 2 presented in Myjava shows that I've been getting the same thoughts regularly since a very long time - because I was frequently hitting this wall. And when I saw your problem it was one of these moments when I was thinking hard about how to adapt fasm 1.x to be able to do this - and each time I was getting a little closer, up until getting the working solution now. I'm glad that you found it helpful, because your problem was among the ones I wanted to address with it. Smile


Hi Tomasz,

so I found that your load directive doesn't support forward references.
This is not easy but I need this in my Sinclair Assembler/BASIC version of FASM. I guess why you don't allow it to be forward referenced because in each pass the code is new generated in an empty buffer which is written with stos cmds.

So it is not easy to find the code placed "later" because it's not already there. So I experimented and think I found out why you do it this way by clearing the complete buffer and create all content new during additional passes. Because it is horrible to move many code portions to make/reduce space for now bigger/smaller instructions or data areas.

So I have lets say following piece of code:

Code:
        AUTOLINE 10

        REM TESTPROGRAMM
lab1:
        REM _asm
        <some asm routine doing something>
        RET
        END _asm

        REM _asm
        <another asm routine doing something>
        RET
        END _asm

        RAND USR #lab1

        IF X=Y THEN GOTO #.loop#

        <more BASIC here>
.loop:
        FOR I=1 TO 10 
        PRINT RAND USR #lab2
        NEXT I
    


Let me explain what's going on there.

I have to mix assembler and BASIC context. This is not that easy as it looks like in the first moment. RAND USR lab1 is for example a valid BASIC statement which starts code at address "lab1" but I have to distinct between the BASIC variable with name lab1 and the assembler label lab1. So I decided to use # as marker for using assembler context and let the following term resolve from FASM engine and not to be treated as a variable.

As I wanted to omit BASIC line numbers I need the possibility to reference a BASIC statement via a label (with start and end # - like #.loop#). This is the part where the load directive would be helpful and come into this game as I need to find out the line number of the next BASIC statement, following that label. The first two bytes are coded as line number and need to be read and stored after the GOTO statement. So I use the code similar to load directive.

But this doesn't work for forward references described ago as the code is not constructed. On the other hand you cannot restrict BASIC programs not to use forward references. This is lets say - more or less inacceptable. So I had to realize. This is now a quick and dirty solution, my hope is you would realize such feature in a future release of FASM.

I forced a minimum of 3 passes using current_path and next_pass_needed and setting them appropriate. So in pass 0 a table of all BASIC line references is prepared - regardless if forward or non-forward. Could be restricted to forward only but was to lazy to do it. I created a static table of 100h entries max. This is what I meant with quick and dirty. In the second pass I check all defined labels, if they are present in that table, mark them and store the resulting line number to this label. So the order of reference doesn't count because the table is created in pass 0 and the labels are resolved in pass 1 with line numbers and in the following passes I create the assembler instructions (codings) with that information, so minimum 3 passes are required if BASIC forward references used at all.

So this might be a concept of realizing forward references for load directive if needed and just add additional passes to resolve the content if needed. Maybe this could be done by not wasting/clearing the last pass but keep it in a temporary memory buffer to allow an access of the last pass with load directive. So just an idea if you might be interesting to have such a feature in future. I find it helpful and maybe there are more constellations where forward references on data would be nice.

As always discussing here on the board - there might be situations that the forward references can not be solved but there are other situations where code could not be generated. So don't care about any case how this feature "can fail". Its in the responsibility of the users.

By the way, I wonder what other use cases are existing for the load/store directive. Just for interest. Wink
So maybe some members here at the board might talk about using load/store in practice.
Post 28 Aug 2013, 23:54
View user's profile Send private message Send e-mail Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1903
DOS386 10 Sep 2013, 09:04
> Hi Tomasz

bumping 1 year old thread Smile))

PS: FASM silently updated today http://board.flatassembler.net/topic.php?t=15738 :

What's new :

* bugfix :

Code:
version 1.71.13 (Sep 09, 2013)

[-] Fixed a bug that caused the expressions containing external symbols
    to overflow from time to time.

version 1.71.12 (Aug 04, 2013)
    


(minor change in FORMATS.INC)

* Recompiled all Win32 and Win64 and Win128 example stuff for no (?) reason (only timestamp changed)
Post 10 Sep 2013, 09:04
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4

< 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 © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.