Index
> Main > flat assembler 1.71.00-01Goto page Previous 1, 2, 3, 4 Next |
| Author |
|
|
shutdownall 22 Sep 2012, 21:17
Are you a troll ?
Or a bot ? Or maybe a troll bot ?  |
|||
22 Sep 2012, 21:17 |
|
|
l_inc 23 Sep 2012, 02:07
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? |
|||
|
23 Sep 2012, 02:07 |
|
|
hopcode 23 Sep 2012, 07:30
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.
Cheers, _________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||
|
23 Sep 2012, 07:30 |
|
|
JohnFound 23 Sep 2012, 07:45
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. |
|||
|
23 Sep 2012, 07:45 |
|
|
Tomasz Grysztar 23 Sep 2012, 12:14
l_inc wrote: One more bug found. The org directive inside of a virtual block allows to cross addressing space limits. l_inc wrote: Btw. should % be valid outside of loops? 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. 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? |
|||
|
23 Sep 2012, 12:14 |
|
|
l_inc 23 Sep 2012, 12:29
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. 
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. |
|||
|
23 Sep 2012, 12:29 |
|
|
Tomasz Grysztar 23 Sep 2012, 12:48
l_inc wrote: Not really. I should have provided the store example: l_inc wrote: That's exactly, what I've already thought about. It would definitely be useful. |
|||
|
23 Sep 2012, 12:48 |
|
|
l_inc 23 Sep 2012, 13:38
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 |
|||
|
23 Sep 2012, 13:38 |
|
|
shutdownall 23 Sep 2012, 21:10
Well - looks good for my codeblock directive planned for my ZX81 Basic version. Mixxing Z80 assembler code with ZX81 Basic instructions.
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.
So I decided to port the Z80 version to new FASM 1.71 next week. |
|||
|
23 Sep 2012, 21:10 |
|
|
hopcode 24 Sep 2012, 15:52
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 
follow that it wouldnt be wrong renaming fasm to "fhla", after "preprocedural" features that induce to a "HLL" (euphemism ) 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:
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 _________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||
|
24 Sep 2012, 15:52 |
|
|
revolution 24 Sep 2012, 15:58
hopcode wrote: ... and perhaps you have no idea from what snapshot the feature can be simply applied in an other way. |
|||
|
24 Sep 2012, 15:58 |
|
|
hopcode 24 Sep 2012, 16:17
revolution wrote: ...would be kind enough to demonstrate the "other way"...We don't appear to be clever enough to work it out 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
...and we will count now the jumping sheep again _________________ ⠓⠕⠏⠉⠕⠙⠑ |
|||
|
24 Sep 2012, 16:17 |
|
|
shutdownall 24 Sep 2012, 16:27
hopcode wrote:
Haha. Irony. Better you count sheeps but better not on this board. Thats my honest opinion.  |
|||
|
24 Sep 2012, 16:27 |
|
|
Tomasz Grysztar 24 Sep 2012, 17:29
shutdownall wrote: Well - looks good for my codeblock directive planned for my ZX81 Basic version. Mixxing Z80 assembler code with ZX81 Basic instructions. |
|||
|
24 Sep 2012, 17:29 |
|
|
shutdownall 24 Sep 2012, 19:33
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 ? 
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 ? |
|||
|
24 Sep 2012, 19:33 |
|
|
Tomasz Grysztar 24 Sep 2012, 19:40
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
). |
|||
|
24 Sep 2012, 19:40 |
|
|
shutdownall 24 Sep 2012, 20:31
Well maybe could answer my questions about structure.
Don't take care about above message, maybe compiled the wrong directory. 
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 ? |
|||
|
24 Sep 2012, 20:31 |
|
|
Tomasz Grysztar 24 Sep 2012, 21:02
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.
|
|||
|
24 Sep 2012, 21:02 |
|
|
shutdownall 24 Sep 2012, 22:56
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 ?? |
|||
|
24 Sep 2012, 22:56 |
|
| Goto page Previous 1, 2, 3, 4 Next < Last Thread | Next Thread > |
Forum Rules:
|