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
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
shutdownall
Are you a troll ? Very Happy
Or a bot ?

Or maybe a troll bot ? Razz
Post 22 Sep 2012, 21:17
View user's profile Send private message Send e-mail Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Seriously though, hopcode, could you explain more graphically what do you mean? Using some pseudo-code or something. In particular, it seems you are mentioning this feature wouldn't be needed if forward-referencing load/store were possible. Could you exemplify this concept? How could Tomasz's LZW example be done with your proposal? (Remember that it is important to not make the output not even one byte larger than actually needed, and also not processing the uncompressed data more than once).
Post 22 Sep 2012, 21:50
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
Tomasz Grysztar
One more bug found. The org directive inside of a virtual block allows to cross addressing space limits:
Code:
virtual
     space:: db 'A'
    org 0
end virtual
db 'B'
load a from space:0
display a,13,10    

Using store in a similar way allows to make fasm crash.

Btw. should % be valid outside of loops?
Post 23 Sep 2012, 02:07
View user's profile Send private message Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
LocoDelAssembly wrote:
Seriously though, hopcode, could you explain more graphically what do you mean? Using some pseudo-code or something. In particular, it seems you are mentioning this feature wouldn't be needed if forward-referencing load/store were possible. Could you exemplify this concept? How could Tomasz's LZW example be done with your proposal? (Remember that it is important to not make the output not even one byte larger than actually needed, and also not processing the uncompressed data more than once).

thanks for taking it seriously. well, i quote it again for those who skipped my posts,
1) here, trying to achieve what is in the first fragment
http://board.flatassembler.net/topic.php?p=148123#148123

2) here,trying to achieve what is in the fragment
http://board.flatassembler.net/topic.php?p=148195#148195

but that is now from me no more a "proposal".
that is a critic from me (constructive in my intention), because i have already posted a proposal on board some/lot of time ago, where in my vision it might have enhanced OOP using assembly, with very little effort.

whether doable or not in that way, one could have been simply stating it: "it is doable/not doable".

also, it seems you have understood well the main matter about code-generation/forward referencing/load-store.

now i think it's too late.
but i accepted it. it's ok even so.
Very Happy

Cheers,

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 23 Sep 2012, 07:30
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, your posts are very blurry and unclear. I simply can't understand what you actually want and what you don't like.
IMHO, no one can understand your posts. Tomasz as well.
So, please try to be more clear - write short sentences and try to provide some examples with explanations what you expect/want to happens and what actually happens.
Post 23 Sep 2012, 07:45
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
l_inc wrote:
One more bug found. The org directive inside of a virtual block allows to cross addressing space limits.
1.71.01 should have it fixed.

l_inc wrote:
Btw. should % be valid outside of loops?
It is simply 0 there, did I not document it? Oh, yes, sorry about it then. This phrase from documentation:
fasm manual, section 1.2.4 wrote:
The other one is %, which is the number of current repeat in parts of code that are repeated using some special directives.
should be supplemented with: "and zero anywhere else".

BTW, the $$ and $ symbols give the information about boundaries of current addressing space. I am thinking: would it be useful to provide some way of extracting this information for labeled addressing space as well?
Post 23 Sep 2012, 12:14
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:
1.71.01 should have it fixed.

Not really. I should have provided the store example:
Code:
virtual
        db 'A'
        org 0
        space::
end virtual 
store $63 at space:0    

makes fasm crash.
Quote:
It is simply 0 there, did I not document it?

It's always possible, that I missed something. Smile
Quote:
would it be useful to provide some way of extracting this information for labeled addressing space as well?

That's exactly, what I've already thought about. It would definitely be useful.
Post 23 Sep 2012, 12: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
l_inc wrote:
Not really. I should have provided the store example:
Code:
virtual
        db 'A'
        org 0
        space::
end virtual 
store $63 at space:0    

makes fasm crash.
Oh, this is a different one. Any "store" outside the boundaries could cause it (if you removed "db" and "org" lines it would probably do the same). It's fixed now.

l_inc wrote:
That's exactly, what I've already thought about. It would definitely be useful.
Do you have some application in mind already?
Post 23 Sep 2012, 12:48
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:
Do you have some application in mind already?

Well... There's no absolute necessity about it. But always whenever accessing a virtual addressing space from outside (especially when at is not specified for the virtual block). You could keep track on the addressing space boundaries by introducing labels or numeric variables (space_begin = $$, space_end = $) from within the addressing spaces or you could access them directly. Just not sure about the syntax.
Code:
;...
virtual
db 'A'
space::
end virtual
;...
load a byte from space:space:$$ ; this looks a little clumsy    
Post 23 Sep 2012, 13:38
View user's profile Send private message Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
shutdownall
Well - looks good for my codeblock directive planned for my ZX81 Basic version. Mixxing Z80 assembler code with ZX81 Basic instructions. Wink

Code:
use16
format binary as "p"

db 100h dup(55h)

codeblocktarget:
 db le-lb dup(0)


virtual at 1000h
  lb:
  my_space::
    db 'My message'
    db 0ffh
    dw lb
  le:
end virtual


repeat le-lb
 load a byte from my_space:1000h+%-1
 store byte a at codeblocktarget+%-1
end repeat
    


So this code can copy any virtual block defined somewhere at any position in output file. This is really a cool feature. Very Happy

So I decided to port the Z80 version to new FASM 1.71 next week.
Post 23 Sep 2012, 21:10
View user's profile Send private message Send e-mail Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
for the last time, i wont to strike a blow for the deprecation of the feature,
that way implemented. i do not claim, i do not pretend.
the feauture brings code to redundancy.

ehi guys, really no commenting from you
on the illusionistic snippets of this thread ? them silently accepted ?
you really have no ideas to improve them using alternatives coming
from years of stable features up to the early 1.69 ?

bad sign. but one marginal question now pops out:
we know that unuseful and reduntant methods of coding have nothing to do
with fasm SSSO principle. thus from one side there's no constraint from the SSSO principle,
because developers have the way they like. on the other side, this is the cleverest principle.
it seems 100% positive the principle. the principle.

we have but the developers too.

in fact one of the practical reasons why developers love/support the SSSO principle
should be simplifying access to the CPU; "what you see is what you get", the "machine",
allowing developers to see the machine and control it using visible opcodes, direct methods
only one step distant from the CPU. capability of an assembler should be
keeping the "step" very short.
in other case they wouldnt be "assembly" developer, or the principle has no reason of being
applied to assembly. too much puristic Question

follow that it wouldnt be wrong renaming fasm to "fhla", after "preprocedural"
features that induce to a "HLL" (euphemism Wink ) coding style. or at least, this is the shadow of a
development line i perceive starting after the half of 1.69 snapshots, to which i wont try any update.

perhaps that's not much clear. anyways, in my intention i wish i had
other major experts get involved into discussion about this and all recent features.

now, two words about this, without blaming etc.
l_inc wrote:
Tomasz Grysztar wrote:
Do you have some application in mind already?
Well... There's no absolute necessity about it. But always whenever accessing a virtual addressing space from outside (especially when at is not specified for the virtual block). You could keep track on the addressing space boundaries by introducing labels or numeric variables (space_begin = $$, space_end = $) from within the addressing spaces or you could access them directly. Just not sure about the syntax.
perhaps you, l_inc, you have no idea about the meaning/use of such a feature.
and perhaps you have no idea from what snapshot the feature can be simply applied in an other way.
then follow that after your (not only you) initial enthusiasm, your being not sure
about the syntax, is a really bad sign too.
hth

Cheers

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 24 Sep 2012, 15:52
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: 16890
Location: In your JS exploiting you and your system
revolution
hopcode wrote:
... and perhaps you have no idea from what snapshot the feature can be simply applied in an other way.
Perhaps you would be kind enough to demonstrate the "other way" with some example code? We don't appear to be clever enough to work it out for ourselves so we need your help.
Post 24 Sep 2012, 15:58
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
revolution wrote:
...would be kind enough to demonstrate the "other way"...We don't appear to be clever enough to work it out
for ourselves so we need your help.
no. sorry. at least for now.
it's not a matter of cleverness, because i consider you all enough clever (and cleverer than me)
to understand/solve with the means fasm already offered.
i am a 360degree open source developer. but i feel no compulsion for it.
this is a matter of seriousness and behaviour; and those people above, read their posts again please,
what type of feedback i received from them. my posts are serious and technological,
even with a bit of irony.

who among them have a real technological interest in fasm development
- at a branch source code level
- at a package level
- at a flexible community-level
Question

...and we will count now the jumping sheep again
Wink

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



Joined: 02 Apr 2010
Posts: 518
Location: Munich
shutdownall
hopcode wrote:

what type of feedback i received from them. my posts are serious and technological,
even with a bit of irony.


...and we will count now the jumping sheep again
Wink


Haha. Irony. Better you count sheeps but better not on this board.
Thats my honest opinion.
Rolling Eyes
Post 24 Sep 2012, 16:27
View user's profile Send private message Send e-mail Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7489
Location: Kraków, Poland
Tomasz Grysztar
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
Post 24 Sep 2012, 17:29
View user's profile Send private message Visit poster's website Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
shutdownall
I have some problems when porting from 1.69.35 to 1.71.01.
In general it is working but crashing (FASM selfending without any message when compiling) with bigger asm files.

Are there particular changes ?
I removed tables.inc and added my tablesz80.inc which contains main parts of symbols and some useful instructions or pseudo instructions or statements.

I found for example the operators section which has been modified.
Probably an error because of non-alphabetic order ? Shocked

definition in 1.69.35
Code:
operators:
 db 1,'+',80h
 db 1,'-',81h
 db 1,'*',90h
 db 1,'/',91h
 db 3,'mod',0A0h
 db 3,'and',0B0h
 db 2,'or',0B1h
 db 3,'xor',0B2h
 db 3,'shl',0C0h
 db 3,'shr',0C1h
 db 0
    


definiton in 1.71.01
Code:
operators:
 db 1,'+',80h
 db 1,'-',81h
 db 1,'*',90h
 db 1,'/',91h
 db 3,'and',0B0h
 db 3,'mod',0A0h
 db 2,'or',0B1h
 db 3,'shl',0C0h
 db 3,'shr',0C1h
 db 3,'xor',0B2h
 db 0
    


Are there more changes this way you keep in mind ?
Do you think there is some code needed from x86.inc ?
I don't think so, otherwise compiling this version would show an error.

These kind of errors are very hard to find as you know, I mean crashing application.

Any idea ?
Post 24 Sep 2012, 19:33
View user's profile Send private message Send e-mail Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7489
Location: Kraków, Poland
Tomasz Grysztar
Oh, there were many important changes in internal structures since 1.69.35, especially since 1.69.41 - so there are many possible sources of the problem. I would probably have to look at what kind of modifications you've done. Though I have to state in advance that I may not have much time for it now (making 1.71.00 and 1.71.01 already exceeded my time quota for fasm in this month Wink).
Post 24 Sep 2012, 19:40
View user's profile Send private message Visit poster's website Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
shutdownall
Well maybe could answer my questions about structure.
Don't take care about above message, maybe compiled the wrong directory. Confused

So get some compiler hints now.

I think you eliminated the section
address_registers:
in tables.inc.

That sucks a bit because I changed this structure to Z80 registers which are now not found.
When compiling LD A,[HL] I get compiler error "reserved word used as a symbol". This was defined as address_register before.

I could go deeper into it but why did you eliminate address_registers and how did you change of use ?
Wink
Post 24 Sep 2012, 20:31
View user's profile Send private message Send e-mail Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7489
Location: Kraków, Poland
Tomasz Grysztar
Oh, the addressing registers are now mixed with regular symbols, and distinguished by a dedicated code after "symbol_value" label in EXPRPARS.INC (basically you jump to "no_address_register" or "register_value" depending on whether the symbol is recognized as allowed in address expression or not). I changed it while I was implementing AVX2 instruction set - and I did consult this change with revolution, who maintains the fasmarm branch, but I did not announce it anywhere else.
Post 24 Sep 2012, 21:02
View user's profile Send private message Visit poster's website Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
shutdownall
Tomasz Grysztar wrote:
depending on whether the symbol is recognized as allowed in address expression or not).

Where did you define if symbol is allowed in address expression ?
Some flag inside tables.inc ??
Post 24 Sep 2012, 22:56
View user's profile Send private message Send e-mail 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.