flat assembler
Message board for the users of flat assembler.

Index > Heap > About arrays in FASM on the Technical Discussion

Author
Thread Post new topic Reply to topic
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
This is what I tried to say

FASM supports numerical constants, it's very useful to hold values that can be used to take decisions, make calculations, store it's content on the output file, etc. However there is some cases where you need to hold many data and you can't know how many constants you will need and possible you neither know in which order you will need to access it (apart of the insanity of declaring a constant for every value you need to hold). For this reason is that I asked "will FASM support arrays (like assembly-time-var[index] = value)", having this you can access an arbitrary index at any time (something that you can't do tricking around this).

I know a workaround to it that consists in using load and store assembler directives but the problem is that in that way the array contents will be stored in the output file (something really not wanted in some cases where you use the array as an auxiliary data structure to do assembly-time things). Of couse you can also use a virtual block to store and work on the array but the problem is that it can only be accessed inside the virtual block which is not very useful if you need the array to do some output on the output file (because FASM has no ways to cross the virtual block limits to reach the file output address space).

Well, that's my idea, hope that is clear now Razz

chat board wrote:

party_crew2: Loco: ugh... no please (vid)
LocoDelAssembly: YES, PLEASE! Very Happy
party_crew2: thats one of most stupid design in MASM


Where it supports it? Confused

Some related links that could be beneficiated of this:
http://board.flatassembler.net/topic.php?p=44949
http://board.flatassembler.net/topic.php?t=4981 <- Here Tomasz talked about "cross-section "store" " which can be a partial solution (also adds some good advantages)

Maybe the Ada syntax idea could be beneficiated of this too (for the argument reordering part), but I think it's not imposible to achieve with the current FASM, it's just a little hard now but that's all. http://board.flatassembler.net/topic.php?t=4648

That's all, thanks again for the good presentations, specially MazeGen for his great ofuscations stuff (the working part Wink) and HyperVista to make possible for us too see the meeting at our homes.

Hey, the others presentations was very good too, but the MazeGen's one had impressed me a lot.
Post 30 Sep 2006, 19:21
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
sorry, i didn't get you at a time.... tomasz has to say the final word
Post 30 Sep 2006, 23:24
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
no problem, with real-time chatting I can't express my ideas well Wink
Post 01 Oct 2006, 00:27
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7718
Location: Kraków, Poland
Tomasz Grysztar
Yes, I'm also sorry that I have understood too late what did you mean. This is actually the problem I met myself many times in the past, as having the assembly-time storage of unlimited length would make it possible to do implement many interesting solutions with interpreted assembler's language, like code compression or gathering data from all the source with option to put it in the beginning of output file.

Yes, I have been thinking about this many times in the past, but never came with any good solution. In the times when the LOAD directive had an option to load directly from file, I was thinking about making STORE symmetrical, so that it could store into files - then you would be able to use some external file as a storage. The only implementation problem was that fasm's OS-dependent interface would have to be extended with some additional function for opening file for writing. Also working with files for storage would perhaps be slow (though with good disk buffering maybe not so much), however this would have an advantage of providing you a way to generate some additional report files etc. And the alternative could be to provide some temporary file-like buffers only in memory for the same purpose.

But finally I never went into that direction, I made the symmetry between LOAD and STORE by disabling the syntax for loading directly from file (now you have to use the combo of VIRTUAL, FILE and LOAD).
The additional reason for not doing it this way is that it would not agree exactly with the concept of code resolving. To make it resolve correctly in all cases, the only true solution would be just something like you proposed - to make it possible for assembly-time constant or variable to hold more than just 64 bits (or any other fixed size). Or make the assembly-time symbol indexable in some way...

Well, I'm making some thoughts right now - there is a possibility that you would declare somehow for parser the array of symbols with the given name, that would then get indexed with numerical expressions at assembly time. The mechanism behind it would be similar to the one of @@ labels, however much work would need to be done inside the assembler. A lot of work, however not as much as with making it possible for single symbol to hold arbitrary-length values.

In that other thread you provided a link to, I mentioned that I don't plan to make such large changes into fasm 1 in any near future. The only new feature coming soon is the generating information about the symbols and connections between source lines and generated output - this was slowly prepared since many releases and is not so far from being finished. But adding the features like assembly-time-arrays would still complicate also this thing...

Well, I think I should just "make first things first". But I'd just like to let you know that I'm aware of this problem.
Post 01 Oct 2006, 19:41
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:
Yes, I'm also sorry that I have understood too late what did you mean.


Well, better for me, this big explanation would be a little hard for me to understand because it's even hard for me hear english than read it Laughing

[edit]
Well now I feel better to see how pathetic was my explanation yesterday, I'll start from scratch now...

My idea for implement this that I think it could be less problematic to achieve and that you don't have to worry about arbitrary lengths is implementing it as a dictionary indexed by integers.

Code:

  dic at 1 = 5 ; Assembler do dic1 = 5
  dic at (dic at 1)  = 'loco' ; Assembler do dic5 = 'loco'

  mov  eax, dic at 5 ; OK ; Assembler do mov eax, dic5
  mov  eax, dic at 2 ; Wrong, used twice below so it's not forward referencable ; assembler do mov eax, dic2
  mov  eax, dic at 100 ; Wrong, since this entry never existed before ; Assembler do mov eax, dic100


  dic at 2 = 10 ; assembler do dic2 = 10
  dic at 2 = (dic at 2) * 2 ; OK ; assembler do dic2 = dic2 * 2

  dic at 4 = (dic at 4) + 1 ; Wrong since the entry 4 never existed before ; assembler do dic4 = dic4 + 1

  a = 5
  dic at a+3 = 3 ; OK since it can be indexed by an expression ; assembler do dic8 = 3
 
  dic at (dic at 200) = 3 ; Wrong since there is no entry 200; assembler can't resolve symbol this time
    


The background behind this is that there is not such dictionary, the assembler actually uses the index to pick a symbol doing something like symbol#index but at assembling time. There is some handling to do in order to avoid colitions with for example a constant "dic2" previously declared by the user that should be diferent to "dic at 2".

This is what I tried to say yesterday. Well the dictionary concept is from today Laughing

[/edit]

Thanks for the detailed answer

PS: Yes, I know you are not planning to add new features now, I'm just giving ideas for the future
Post 01 Oct 2006, 23:52
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Edited, if you already read the previous post then sorry for waste your time
Post 02 Oct 2006, 14:43
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Code:
dic at (dic at 1)  = 'loco'    

I forgot to point something about that line, I'm not proposing supporting arbitrary length strings, the current fasm allows to do "var = 'loco'" but not "var = 'very long string'". Maybe could be a great feature supporting arbitrary length strings but it's not the intention of this thread propose such feature.
Post 29 Nov 2006, 21:11
View user's profile Send private message 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 can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.