fasmg feature requests

Index > Programming Language Design > fasmg feature requests

Author

Thread

jmg

Joined: 18 Sep 2016
Posts: 62

jmg 24 Sep 2016, 00:52

fasmg is impressive, but there are some small changes that would help use.

Starting with the smallest...

a) Can the time taken be reported to more digits. .1s is quite coarse.
eg 1ms LSB would be better, below most OS jitter.
Reason: when checking for no-surprises and improving speed, small changes are usefully tracked.

b) The error message has a [Line Num] tag, which is ok for main ASM, but less use inside a macro, as not easy to find macro line [14], & do I count from macro headline, or next line....

Can the error message include the offending string, to avoid tedious line counting.
Some assemblers report Line#,Column#, which is more useful.

c) There seems to be no Change Log on the fasmg download, either before, or after unzip.
The download is not large, but unpack all takes time & it is useful to know what has changed, to know what to look out for...

24 Sep 2016, 00:52

Tomasz Grysztar

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

Tomasz Grysztar 24 Sep 2016, 05:05

jmg wrote:

a) Can the time taken be reported to more digits. .1s is quite coarse.
eg 1ms LSB would be better, below most OS jitter.
Reason: when checking for no-surprises and improving speed, small changes are usefully tracked.

On a multitasking OS the second digit wouldn't mean much, as the time between consecutive runs may semi-randomly change even more than that. Perhaps when writing an interface for a single-task OS I could consider displaying more digits (because, the same as in the case of fasm, it is the interface that decides what is displayed and in what format). But fasm, even though it has DOS version that fasmg does not, never displayed more than one digit either - even though the additional digit could perhaps have more meaning there, considering that fasm is usually much faster.

jmg wrote:

b) The error message has a [Line Num] tag, which is ok for main ASM, but less use inside a macro, as not easy to find macro line [14], & do I count from macro headline, or next line....

The macro header is line 0, so if you add the number of line inside macro to the number of macro header line, you should get the number of line in source file (as long as it is the macro that has a plain definition in source text).
Still, the interface should display the line that caused an error, just like fasm does - I just forgot about it (apparently it never bothered me much).

jmg wrote:

c) There seems to be no Change Log on the fasmg download, either before, or after unzip.
The download is not large, but unpack all takes time & it is useful to know what has changed, to know what to look out for...

There is no list of changes like in the case of fasm, because fasmg still has not started having regular releases like fasm does. The updates are just a snapshots of the repository, but as repository log shows, the most of the changes during the last year have been related to the work on examples and documentation, and this is going to continue. Recent period was exceptional, as I finally implemented a few missing features that waited long before I found the right syntax for them, but this is not going to be usual.

24 Sep 2016, 05:05

jmg

Joined: 18 Sep 2016
Posts: 62

jmg 24 Sep 2016, 05:21

Thanks.

Tomasz Grysztar wrote:

jmg wrote:
a) Can the time taken be reported to more digits. .1s is quite coarse.
eg 1ms LSB would be better, below most OS jitter.
Reason: when checking for no-surprises and improving speed, small changes are usefully tracked.
On a multitasking OS the second digit wouldn't mean much, as the time between consecutive runs may semi-randomly change even more than that.

I've coded other timing-run software, and yes, you are partly right.
The OS can and does add jitter to reading, however, the OS never runs faster, (it only steals cycles), and also usually adds in Quanta to a reading, so that means you can get useful timings every with OS effects, because you can discard unusual or high results, and converge on a lower value.

I have found even high-speed timers and sub-milliseconds times can be captured to quite good precision, if you are prepared to take more than one reading, and discard some results.

For fasmg, I'd suggest reporting to 1ms is fine, and users can make their own judgments on what jitter that gives on their individual systems.
Multiple identical runs easily reveals that.

24 Sep 2016, 05:21

Tomasz Grysztar

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

Tomasz Grysztar 24 Sep 2016, 05:28

jmg wrote:

I've coded other timing-run software, and yes, you are partly right.
The OS can and does add jitter to reading, however, the OS never runs faster, (it only steals cycles), and also usually adds in Quanta to a reading, so that means you can get useful timings every with OS effects, because you can discard unusual or high results, and converge on a lower value.

I have found even high-speed timers and sub-milliseconds times can be captured to quite good precision, if you are prepared to take more than one reading, and discard some results.

For fasmg, I'd suggest reporting to 1ms is fine, and users can make their own judgments on what jitter that gives on their individual systems.
Multiple identical runs easily reveals that.

I still would prefer to not break fasm's long tradition without a really good reason. Wink

If you plan to make multiple controlled measurements then you can probably use some good dedicated tools for that.

24 Sep 2016, 05:28

jmg

Joined: 18 Sep 2016
Posts: 62

jmg 24 Sep 2016, 06:05

ok, your call Smile

I usually would not consider the number of digits after a decimal point, anywhere near 'a tradition'.
In this part of the world, that's more a 'trifling detail'.

24 Sep 2016, 06:05

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20300
Location: In your JS exploiting you and your system

revolution 24 Sep 2016, 19:14

Something I'd like to see in fasmg (actually I've mentioned it before, but perhaps this thread is a better place) is to have some sort of macro compiler for faster processing when using large sources. Although I realise that it would be complex.

A secondary intermediate step might be an internal tokeniser (or equivalent) to avoid having to reprocess text on each pass. Once again in the desire towards faster processing overall.

But both of these things I do not consider vitally important. Just a nice to have thing.

24 Sep 2016, 19:14

Tomasz Grysztar

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

Tomasz Grysztar 24 Sep 2016, 20:17

revolution wrote:

Something I'd like to see in fasmg (actually I've mentioned it before, but perhaps this thread is a better place) is to have some sort of macro compiler for faster processing when using large sources. Although I realise that it would be complex.

This is an interesting idea, to say the least.

revolution wrote:

A secondary intermediate step might be an internal tokeniser (or equivalent) to avoid having to reprocess text on each pass. Once again in the desire towards faster processing overall.

fasmg already uses two layers of internal tokenisers and macros are stored as a list of tokens than only contain pointers to some original text data where needed, and every name token also comes with pre-calculated hashes (both case-sensitive and case-insensitive one) to make look-ups faster. But this is still not as good as fasm's internal bytecode where tokens no longer have any connection to text whatsoever, and they point directly to symbol structure.
In the original thread about fasmg I mentioned that I was dreaming about some kind of "the best of both worlds" solution that would combine the macro capabilities of fasmg with the performance of internal bytecode of fasm. Unfortunately, this is not possible without sacrificing some of the basic features of fasmg's language and I was aware of it since I started working on it (someone might have noticed that I even briefly mentioned this problem in my talk about fasm 2 on fasmcon 2009). This is because in fasmg the meaning of any word or identifier may be constantly in flux, and simplifying it back into something more fasm-like would in fact require designing yet another, even if similar, language.

24 Sep 2016, 20:17

jmg

Joined: 18 Sep 2016
Posts: 62

jmg 25 Sep 2016, 00:24

revolution wrote:

Something I'd like to see in fasmg (actually I've mentioned it before, but perhaps this thread is a better place) is to have some sort of macro compiler for faster processing when using large sources. Although I realise that it would be complex.

A secondary intermediate step might be an internal tokeniser (or equivalent) to avoid having to reprocess text on each pass. Once again in the desire towards faster processing overall.

But both of these things I do not consider vitally important. Just a nice to have thing.

Interesting idea, like a JIT script engine ?

One thing I noticed in my tests, was the fasmg speed was much slower with listing enabled, but some sort of listing is usually needed in assembler development.

; Listing ON -> 2 passes, 2.4 seconds, 16547 bytes, 266k LST
; Listing OFF -> 2 passes, 0.4 seconds, 16547 bytes, 80 byte LST

It may be initially more fruitful to support faster listing options, than to do a fancy JIT flow ?

25 Sep 2016, 00:24

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20300
Location: In your JS exploiting you and your system

revolution 25 Sep 2016, 06:49

No, not a JIT. A static compile. Changing only when the source macros change, not for each assembly session. Kind of like fasm.exe only needs to change when the fasm sources change, not each time I assemble MyUberProggy.asm.

As for listing, I find for me it is only needed for end user documentation to comply with our contract obligations. Otherwise I wouldn't use it.

And if you are in an environment of rapid changes being downloaded on demand (like many applications these days like to do), then a listing file can be out of date within a matter of seconds and thus useless for anything serious.

25 Sep 2016, 06:49

< 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