flat assembler
Message board for the users of flat assembler.

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: 6873
Location: Kraków, Poland
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: 15871
Location: 162173 Ryugu
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: 6873
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: 15871
Location: 162173 Ryugu
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: 4160
Location: 2018
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: 6873
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: 257
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 Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15871
Location: 162173 Ryugu
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: 257
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 0x55, 0xAA 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 Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15871
Location: 162173 Ryugu
Tomasz Grysztar wrote:
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 tried this new feature just now and got a bad filename output. fasm tries to save an invalid name to disk. I used the pre-built console exe that was in the download and a newly assembled exe, both failed.

Edit: I'm using v1.73.01
Post 26 Dec 2017, 04:23
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6873
Location: Kraków, Poland
Could you provide a little more info on the environment, file paths and command line arguments?

Edit: I think I found it. The bug shows up when the "-s" switch is used.
Post 26 Dec 2017, 10:15
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: 15871
Location: 162173 Ryugu
Tomasz Grysztar wrote:
Could you provide a little more info on the environment, file paths and command line arguments?

Edit: I think I found it. The bug shows up when the "-s" switch is used.
I only used the plain invocation "fasm filename.asm" with the contents of the file being the exact text in your post. fasm then saved filename.bin okay, but failed to save filename.tbl. It tried to save filename.??? with three invalid/random characters that are different each time it is run.


Last edited by revolution on 26 Dec 2017, 15:30; edited 1 time in total
Post 26 Dec 2017, 11:28
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6873
Location: Kraków, Poland
Please try 1.73.02.
Post 26 Dec 2017, 11:44
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: 15871
Location: 162173 Ryugu
Working fine now.
Post 26 Dec 2017, 12:30
View user's profile Send private message Visit poster's website 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


Copyright © 2004-2018, Tomasz Grysztar.

Powered by rwasa.