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  Next
Author
Thread Post new topic Reply to topic
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
...then by counting sheep Very Happy i was suddenly
awakened from the kipple above, with the question:
if addresses are essentially run-time addresses, what would be
addressoids ? they would be "oida" i.e." seems like an address but it isnt." ok.
are they virtual ? no. they are only a special non-place in a dream. ergo:
do addressoids dream of electric sheep ? Very Happy
i wait eh !

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 21 Sep 2012, 12:50
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7489
Location: Kraków, Poland
Tomasz Grysztar
l_inc wrote:
You wrote, that the addressing spaces cannot be forward referenced. Not the labels.
Yes, I did not state that correctly even though I had labels in mind. Please forgive me, it was late in the night. Wink

I uploaded another update of 1.71.00 packages (since it is still within the first 24 hours I do not make a new version yet) - the reported bugs are fixed, please try it.
Post 21 Sep 2012, 13:00
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
Tomasz Grysztar
Quote:
Yes, I did not state that correctly even though I had labels in mind.

Wouldn't this be a kind of forward referencing? I'm still not sure, I clearly understand all of the use cases, where this rule applies.
Code:
if used space
     display 'Space used',13,10
end if

space::
db 'ABCD'
load a byte from space:$$    


P.S. Probably it would be more consistent to allow forward referencing of such labels, but not forward referencing of the data (as it's used to be).
Post 21 Sep 2012, 13:17
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7489
Location: Kraków, Poland
Tomasz Grysztar
This will work, it is analogous to the case of re-defined numerical variable, which also cannot be forward referenced by itself, but you are free to check its "used" status anywhere:
Code:
if used tester
        display 'Tester used',13,10
end if

; this would cause error:
; dd tester

tester = 0

tester = 1

dd tester    


PS But "defined" has not yet been upgraded to work correctly with these new labels, please wait for another update.
Post 21 Sep 2012, 13:22
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
Tomasz Grysztar
Quote:
But "defined" has not yet been upgraded to work correctly with these new labels, please wait for another update.

As for me, it works as expected:
Code:
if defined space
      display 'space defined 1',13,10
end if

space:: db 'ABCD'

if defined space
      display 'space defined 2',13,10
end if    

displays "space defined 2" only.
I don't see any point of making it display both strings, because in this case it would be impossible to detect whether such label is allowed to be used at current code location.

P.S. Or again, you could allow the addressing space labels to be forward referenced, as I mentioned before, because their semantics is nearer to the normal labels than to the redefined numerical variables.
Post 21 Sep 2012, 13:29
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7489
Location: Kraków, Poland
Tomasz Grysztar
Yes, it works as it should in this case.

l_inc wrote:
P.S. Or again, you could allow the addressing space labels to be forward referenced, as I mentioned before, because their semantics is nearer to the normal labels than to the redefined numerical variables.
The fact that they can only be forward-referenced comes from the internal gimmicks, I had to adapt the definition to the limitations of implementation here. But it is not a big deal, IMHO.
Post 21 Sep 2012, 15:44
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
Tomasz Grysztar
Quote:
Yes, it works as it should in this case.

OK. Then we do not expect any updates currently.
Quote:
The fact that they can only be forward-referenced comes from the internal gimmicks

I assume, you mean "can not be forward-referenced".
Quote:
But it is not a big deal, IMHO.

I currently do not see any practical necessity in such things (forward referencing an addressing space label to access the previously defined data):
Code:
db 'ABCD'
virtual
      load a from space:data_end-1
    display a,13,10
end virtual
space:: data_end:    

This works for data_end, but not for space. I just thought, it was an intentional design decision rather than a required measure.
Post 21 Sep 2012, 16:03
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7489
Location: Kraków, Poland
Tomasz Grysztar
l_inc wrote:
I assume, you mean "can not be forward-referenced".
Yes. Sorry, I keep saying not what I had in mind. Wink

l_inc wrote:
I just thought, it was an intentional design decision rather than a required measure.
The fact is, I would probably be able to find a way around it and implement this one special case (forward-referencing label that marks the same space as the current one), but I think that the simple rule of no forward references makes things much more plain and simple, and we are not losing much.
Post 21 Sep 2012, 16:07
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
Tomasz Grysztar
Quote:
I would probably be able to find a way around it and implement this one special case (forward-referencing label that marks the same space as the current one)

My previous example is directed to point out, that the case is a little wider. It does not contain forward referencing of data or an addressing space, but the forward referenced addressing space label does not belong to the current space.
Quote:
I think that the simple rule of no forward references makes things much more plain and simple, and we are not losing much.

IMHO it's equally plain and simple from the user's point of view. But as I said, absolutely not a problem for me.
Post 21 Sep 2012, 16:21
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
Bug report:
Code:
virtual at 0
  __address_space1::
        db 1
end virtual

__address_space2::
       rb 1

store byte 1 at __address_space1:0

;db 1   ; this fixes the binary.    


Generates huge file full with random data.
Defining even one byte at the end fixes the problem.

_________________
Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
Post 21 Sep 2012, 17:52
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7489
Location: Kraków, Poland
Tomasz Grysztar
Fixed.
Post 21 Sep 2012, 18:16
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
Very Happy the feature ?
Cool space:address

Very Happy what the use?
Cool forward-referencing not yet generated code but
loaded one byte at a time, this last time.

Very Happy is it something new ?
Twisted Evil yes. but it has 2 main reasons:
-one, it is needed to forward-reference the matter in a later time
-two, because forward-referencing itself is a trend now.

Very Happy ok. i wait,
i count sheep...
one two three nth, oops,oops
jumping
oops
...

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 21 Sep 2012, 19:23
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
hopcode, IMHO, you need to get some sleep.
Post 21 Sep 2012, 20:08
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
cod3b453



Joined: 25 Aug 2004
Posts: 619
cod3b453
I think I hit one of the cases fixed above, but now seems to work very nicely!

Already managed to convert some basic macros into LUT-driven variants and crypto/hash functions should be a lot easier/possible now! (at least without the need to chop a few kB form the end of the file where the state was kept! Laughing) Another interesting aspect to this is that the preprocessor can now create, reference and share dynamic structures in these virtual address spaces:
Code:
macro @make_a_thing id
{
        virtual at 0
            id#::
                .stuff rd 1
        end virtual
}

macro @use_a_thing id
{
        local d

        store dword 'x' at id#:.stuff
        load d dword from id#:.stuff

        display d
}

@make_a_thing x
@use_a_thing x
@use_a_thing x    
Insanely powerful stuff Cool
Post 22 Sep 2012, 14:29
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7489
Location: Kraków, Poland
Tomasz Grysztar
cod3b453 wrote:
Another interesting aspect to this is that the preprocessor can now create, reference and share dynamic structures in these virtual address spaces.
The preprocessor has no access to these features, because LOAD/STORE directive operate at assembly time. But yes, you can now create dynamic structures (buffers, tables, etc.) and use them freely in the assembly-time language, while earlier you could only use simple variables (defined with "=") which could store only a single number each. Now you can keep an array of bytes on the side and do whatever you want with them.
Post 22 Sep 2012, 15:00
View user's profile Send private message Visit poster's website Reply with quote
cod3b453



Joined: 25 Aug 2004
Posts: 619
cod3b453
Hi Tomasz,

(Sorry, yes, assembly time Embarassed)

I've just hit a bit of a problem in this sort of code:
Code:
my_label:

        jmp .next ; <- cannot find my_label.next

; from macro
virtual at 0
        try::
        .that dd 0
        .this dd 0
;       .next dd 0 ; <- would fail due to redefinition
end virtual
;end macro

.next: ; <- renamed to try.next

dd .this ; previously non-existent    
I think this follows from what others mentioned earlier in the thread about clashing but I wasn't expecting try to replace my_label. I'm wondering if "::" labels could be restricted to only virtual sections and that when end virtual is reached the previous label was restored? (with the virtual labels still being available by explicit reference - try.that etc) I don't think this would break either the previous or new functionality and should then provide explicit separation of the address spaces Question
Post 22 Sep 2012, 15:52
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7489
Location: Kraków, Poland
Tomasz Grysztar
These special labels follow all the same rules as regular ones, and so you deal with name conflicts in exactly the same way. If you replaced "try::" with a simple "try:" you would still have the same problem. And so the solution is exactly the same as in the standard case, use "..try" instead of "try".
Post 22 Sep 2012, 15:59
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
ok. i accept it.
...but all the sheep jumped ? Very Happy
Tomasz Grysztar wrote:
The preprocessor has no access to these features, because LOAD/STORE directive operate at assembly time. But yes, you can now create dynamic structures (buffers, tables, etc.) and use them freely...
ergo, what i said above in my post
hopcode wrote:
...wouldnt it be simply better to consolidate/extend the load/store things even on not yet assembled code, instead of creating such
new feature that, at least for now, seems to assert just now, completely
and openly again, the weakness of virtual ?...


note please that you could have it done even in other ways, for example using the space?address form or extending the same virtual directive in this way, accepting the ? on it:
Code:
virtual at ?
...
end virtual
    
this could have automatically extended all structuring (by struc) and on the developer side, all ovelapping of structures on registers/offsets and spacenames, yes, too.
if you called it virtual, it must be virtual, right ?
now we need a regexp engine to work with all those ::: Smile

Cheers,

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 22 Sep 2012, 18:15
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7489
Location: Kraków, Poland
Tomasz Grysztar
hopcode, I really don't understand any of your posts here.
Post 22 Sep 2012, 18:27
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
Tomasz Grysztar wrote:
hopcode, I really don't understand any of your posts here.
that'all. it's not so important what i say. matter is the concrete feedback i receive, after i post.

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 22 Sep 2012, 18:48
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  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 © 1999-2019, Tomasz Grysztar.

Powered by rwasa.