flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Main > flat assembler 1.73.00

Author
Thread Post new topic Reply to topic
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6676
Location: Kraków, Poland
flat assembler 1.73.00
This is the first release of a new development line, open for experiments.

This version adds the feature of storing VIRTUAL blocks as auxiliary output files, backported from fasmg. It works more or less the same as there:

Code:
virtual at 0 as 'tbl'
    times 256 db %-1
end virtual

I'm also going to attempt backporting the reopening of VIRTUAL blocks feature, though its implementation into fasm 1 engine would have to be suboptimal.

Note that this is pushing fasm 1 engine into new territories, be wary of possible bugs.
Post 24 Nov 2017, 23:08
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: 15303
Location: Bigweld Industries
I am glad to see fasm getting some attention again. Smile
Post 25 Nov 2017, 00:20
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6676
Location: Kraków, Poland
And the version 1.73.01 follows almost immediately, with finished the VIRTUAL features backporting. It now allows to "reopen" VIRTUAL block just like fasmg:

Code:
    virtual at 0 as 'log'
        Log::
    end virtual

    virtual Log
        db 'Hello!',13,10
    end virtual



There is one known issue - fasm 1 unlike fasmg is not able to track the uninitialized data inside VIRTUAL blocks, so any data declared with "?" is going to be stored in the auxiliary file anyway. But I don't know if fixing this is really worth pursuing.
Post 25 Nov 2017, 11: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: 15303
Location: Bigweld Industries
This would create a large output file.

Code:
virtual at 0 as 'buffers'
  buffer1 rb 1 shl 26
  buffer2 rb 1 shl 26
  buffer3 rb 1 shl 26
end virtual

But I don't see how it would be useful to anyone. Maybe it can be left as defined behaviour to "punish" people who try to use such things. Twisted Evil
Post 25 Nov 2017, 14:11
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4157
Location: achtétépéhèseu://pasteubineu.comeu/Vw7WXXf4
very very cool feature.

apparentlly, it cannot be used to compile auxilary executable files.

Code:

virtual at 0 as 'exe'
        include 'g:/fasmw/source/ide/fasmw/fasmw.asm'
end virtual





indeed, it's very good to compile bunch of datas to test with the code, in a single source file Wink
Post 26 Nov 2017, 16:54
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


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

edfed wrote:
apparentlly, it cannot be used to compile auxilary executable files.

You could attempt it with fasmg, but in fasm 1 the formatter cannot be encapsulated like that.
Post 26 Nov 2017, 21:48
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 88
Location: Belarus

Tomasz Grysztar wrote:
There is one known issue - fasm 1 unlike fasmg is not able to track the uninitialized data inside VIRTUAL blocks, so any data declared with "?" is going to be stored in the auxiliary file anyway. But I don't know if fixing this is really worth pursuing.


I’ve been thinking about the problem recently. IMHO, it might be useful for sets of macros for generating, say, disk images (my use case) while allowing some pieces like a bootsector being written by hand: such pieces might use uninitialized data at the end of the block (especially beyond the 512 bytes that must be put into the image).

I don’t really think the feature is strictly necessary (simply cutting the block to the expected size might work in most cases), just wanted to let you know someone still using fasm 1 has recently thought about it.
Post 27 Nov 2017, 15:36
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15303
Location: Bigweld Industries

DimonSoft wrote:
... such pieces might use uninitialized data at the end of the block (especially beyond the 512 bytes that must be put into the image).

If you need padding data then you shouldn't use the uninitialised data definition for that. It it has to be included then you should be initialising it just to make sure you get what you intend.
Post 27 Nov 2017, 22:13
View user's profile Send private message Visit poster's website Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 88
Location: Belarus

revolution wrote:

DimonSoft wrote:
... such pieces might use uninitialized data at the end of the block (especially beyond the 512 bytes that must be put into the image).

If you need padding data then you shouldn't use the uninitialised data definition for that. It it has to be included then you should be initialising it just to make sure you get what you intend.


Maybe I wasn’t clear (not a native speaker). What I meant is something like:

Code:
Offset   0  Up to 510 bytes of code and initialized data
            Some padding (optionally)
            db 0x550xAA

Offset 512  Uninitialized data goes here


It might be pretty safe to access the memory between 0x0:0x7E00 and 0x0:0x8000 but since BIOS just loads 512 bytes you can only put uninitialized data after them (as a way to define “typed” labels for your temporary storage). I guess, this won’t work if put inside virtual block.

Although (1) BIOS is considered out-of-date these days and (2) hundreds of boot sectors already exist that do not require such tricks, tracking the uninitialized data in virtual blocks might be of use in similar cases, not related to osdev. I don’t know if it happens often: the use case I describe was my first one (and the only for now), and even then I didn’t really need it myself, just thought about possible use cases.
Post 28 Nov 2017, 07:15
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 cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.