[feature request] "truncate" assembler directive

Index > Compiler Internals > [feature request] "truncate" assembler directive

Author

Thread

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 21 Mar 2006, 17:27

Apart of "base explicit" idea now I have the idea of the "truncate" directive. Is possible something like that? Normally you don't need something like that but suppose the case in which you have a compression macro, it's clear that the already generated output will be bigger so, how do you eliminate the reminder bytes?

Example:

Code:


.data

Compress_block

aString db "Hello world", 0
anotherString db "bye bye world",0

end_block ; Compress and reserves (uses rb) space for decompression

; Don't put any data initialized data here

In that example Compress_block just take note of "$" to be used in end_block, end_block will compress the data and reserve the saved bytes. Since reserved bytes (rb) reserves the memory without getting the file bigger you get an smaller executable file but since there is no way to truncate the block we will have the compressed data plus the saved bytes initialized (and getting the file with the same size as without compression).

What do you think?

Hope this idea doesn't disturb you Wink

Regards

21 Mar 2006, 17:27

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8390
Location: Kraków, Poland

Tomasz Grysztar 21 Mar 2006, 18:13

By implementing the "load"/"store" that were a bit contrary to the original fasm's ideal of always making sure that all generated values are correct (well, they are not really contrary to that if you understand them in a appropriate way; how it does interact with relocations deserves a separate article) I already weakened that law, thus it is no longer so strong as to oppose such additions. However this breaking of that law would be even stronger and I did not implement it because of some interactions that I was not really aware of what would they lead to. Like what would happen if we had some relocations for the truncated area... Also it would be a quite complicated thing to explain the manuals, requiring a note like "only for advanced users that really understand what does it do".

I would be still possible to make such compression for data only by re-defining the data directives appropriately. You could make them compress data "on fly", or once at the end of block, like:

Code:

macro Compress_block
{
  BlockStart:
  CurrentAddr = BlockStart
  struc db [data]
  \{
    \common
    virtual at CurrentAddr
     . db data
     CurrentAddr = $
    end virtual
    match list,list@db \\{ list@db equ list@db,data \\}
    match ,list@db \\{ list@db equ data \\}
  \}
  list@db equ
}

macro end_block
{
  restruc db
  UncompressedSize = CurrentAddr - BlockStart
  times CompressedSize db 0
  InOffset = 0
  OutOffset = 0

  while InOffset<UncompressedSize
   virtual at 0
    db list@db
    load a byte from InOffset
   end virtual
   InOffset = InOffset+2
   if BlockStart+OutOffset<$
    store byte a at BlockStart+OutOffset
   end if
   OutOffset = OutOffset+1
  end while

  CompressedSize = OutOffset

  rb UncompressedSize-CompressedSize
}



Compress_block

aString db "Hello world", 0
anotherString db "bye bye world",0

end_block

(it doesn't do any real compression, it just skips one of every two bytes solely for demonstration purposes).
Well, actually it could be a bit simpler:

Code:

macro end_block
{
  restruc db
  UncompressedSize = CurrentAddr - BlockStart
  InOffset = 0

  while InOffset<UncompressedSize
   virtual at 0
    db list@db
    load a byte from InOffset
   end virtual
   InOffset = InOffset+2
   db a
  end while

  rb UncompressedSize-($-BlockStart)
}

But if you think it's still an overkill, then you're right. Laughing

Some cross-section "store" would be really helpful for such things, but I haven't yet invented any good idea for it (other than allowing to "store" into external file; too bad I fixed the symmetry between "load" and "store" by removing the "load from file" syntax instead of adding "store to file" one Wink

).

PS. I don't plan adding any new features in the near future other than some formatter additions. Documenting what already is there seems to be more important now. Making some kind of debug-info output was also on that TODO list, but you see, because fasm contains so many specific features it's not so simple thing - at least I already realized that fasm's needs own debug-info format, because no other format is adapted for containing the kind of information fasm can provide (which is very far away from the informations that compilers usually provide).

21 Mar 2006, 18:13

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 21 Mar 2006, 21:35

Well I shown that example because I'm thinking in a way to compress strings by using 6 bits per char (still not implemented). But in the case of trying to compress code then you can't do the same because you can't make lists in assembly time. I didn't saw the relocations problem so now I don't think that it could be an easy to implement addition anymore.

About you don't plan to add nothing right now it's OK, I'm agree with you that those things has more priority, I'm just giving ideas now because FASM is not in "milestone" stage but in development stage.

Regards

PS: Thanks for the idea of restructuring "db" Very Happy

21 Mar 2006, 21:35

< 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