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 |
|
Tomasz Grysztar 25 Sep 2012, 08:12
shutdownall wrote: Where did you define if symbol is allowed in address expression ? |
|||
25 Sep 2012, 08:12 |
|
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. Are you sure ? 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 |
|||
25 Sep 2012, 11:59 |
|
revolution 25 Sep 2012, 12:16
shutdownall wrote:
|
|||
25 Sep 2012, 12:16 |
|
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. Ah okay - it is just the high nibble. Okay - I will keep a look at it. |
|||
25 Sep 2012, 12:48 |
|
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 . |
|||
25 Sep 2012, 13:09 |
|
revolution 25 Sep 2012, 13:18
shutdownall wrote: Ah okay - it is just the high nibble. Quote: See "symbol_value:" in EXPRPARS.INC to follow the decoding of the table entries. |
|||
25 Sep 2012, 13:18 |
|
revolution 25 Sep 2012, 13:20
l_inc wrote: revolution |
|||
25 Sep 2012, 13:20 |
|
l_inc 25 Sep 2012, 13:32
revolution
mz was more a kind of a joke. But you didn't comment the other ones. |
|||
25 Sep 2012, 13:32 |
|
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. When all else fails, read the source. |
|||
25 Sep 2012, 13:32 |
|
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. |
|||
25 Sep 2012, 13:36 |
|
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. +1 from me to your extradimensional patience Cheers, _________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||
25 Sep 2012, 13:38 |
|
shutdownall 30 Sep 2012, 00:26
Tomasz Grysztar wrote:
Thank you Tomasz. So first piece of work is done. 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. Answers from revolution are appreciated in the same way as he did for ARM. |
|||
30 Sep 2012, 00:26 |
|
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 |
|||
08 Oct 2012, 05:15 |
|
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.
It should be OK now (1.71.04). |
|||
08 Oct 2012, 06:42 |
|
l_inc 08 Oct 2012, 16:38
Tomasz Grysztar
Your bugfixes are always so fast. You might never be sleeping. |
|||
08 Oct 2012, 16:38 |
|
shutdownall 28 Aug 2013, 23:54
Tomasz Grysztar wrote:
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. So maybe some members here at the board might talk about using load/store in practice. |
|||
28 Aug 2013, 23:54 |
|
DOS386 10 Sep 2013, 09:04
> Hi Tomasz
bumping 1 year old thread )) 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) |
|||
10 Sep 2013, 09:04 |
|
Goto page Previous 1, 2, 3, 4 < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.