flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > [split-off] Problem with fasmg ik0iv

Author
Thread Post new topic Reply to topic
bitRAKE



Joined: 21 Jul 2003
Posts: 4060
Location: vpcmpistri
bitRAKE 16 Jun 2019, 11:49
I'm going to stick with version "ijlx0" for now - that version has some strangeness. Haven't narrowed it down. Something about a scoping change, but when I try fragments of code - they work.
Post 16 Jun 2019, 11:49
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 16 Jun 2019, 12:16
bitRAKE wrote:
I'm going to stick with version "ijlx0" for now - that version has some strangeness. Haven't narrowed it down. Something about a scoping change, but when I try fragments of code - they work.
The only difference in fasmg's core since that version is that I added special handling for "." label, making it update what is considered the "current base label" for other symbols starting with dot. This normally does nothing (because "." already is that label), but in case when something like ".:" is used inside STRUC macro, it now updates the "current base label" where previously it would not.

It was another instance of my continued efforts to make the changed behavior of these labels work as expected. The original fasmg's design was a clean rule that had no special cases, but it was problematic where it did not follow what fasm 1 would do, so I finally gave in and changed it - but then I had to introduce a couple of exceptional cases like this one to keep this working as expected. Under original system ".:" in STRUC macro was becoming the latest label within its namespace without any special treatment.
Post 16 Jun 2019, 12:16
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 4060
Location: vpcmpistri
bitRAKE 16 Jun 2019, 12:40
Is this still valid syntax?
Code:
struc EXCEPTION_POINTERS
label .
namespace .
PEXCEPTION_RECORD       rq      1       ; ExceptionRecord
PCONTEXT                rq      1       ; ContextRecord
end namespace
end struc    
...which then I use in both data section and virtual. Removing that file did eliminate the error.

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup
Post 16 Jun 2019, 12:40
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 16 Jun 2019, 12:49
There is nothing wrong with this syntax, the questions is what behavior do you expect when this is put in context. Here a simple snippet that demonstrates what changed:
Code:
first:
second EXCEPTION_POINTERS
  .test = 1

if defined first.test
        display 'g.ijlx0'
else if defined second.test
        display 'g.ik0iv+'
else
        display '?'
end if    
Post 16 Jun 2019, 12:49
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 4060
Location: vpcmpistri
bitRAKE 16 Jun 2019, 13:17
Code:
first:
.second EXCEPTION_POINTERS
  .test = 1    
Gives me a "?" That is my typical use case. If I remove "label ." then the expected "first.test" works, but "first.second" is not defined. Makes me think I've been using this wrong all along, lol. Surprised anything worked.

Changing "label ." to ".=$" might be the correct change - seems to have the intended result. Thanks for the help.
Post 16 Jun 2019, 13:17
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 16 Jun 2019, 13:48
bitRAKE wrote:
Gives me a "?" That is my typical use case.
OK, I see the problem, this should actually inherit the "localness" of the ".second" label. This may require a more clever fix.
Post 16 Jun 2019, 13:48
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 16 Jun 2019, 15:30
Tomasz Grysztar wrote:
This may require a more clever fix.
I believe I found a solution. Not very pretty, but it works.

bitRAKE: please try it with "il0vt".
Post 16 Jun 2019, 15:30
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 4060
Location: vpcmpistri
bitRAKE 16 Jun 2019, 20:32
Tried to break it, but I couldn't. I'll need more time. Razz

Thank you.

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup
Post 16 Jun 2019, 20:32
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:  


< 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.