I've released the new version of flat assembler
(at http://omega.im.uj.edu.pl/~grysztar)
with many improvements.
All macroinstructions were rewritten for better performance,
so please update your .inc files when changing to 1.20

Also new pre-pre-release of Assembler Workplace,
with "Run" command, is available.
Posted on 2001-11-20 05:03:02 by Tomasz Grysztar
Brilliant job you've done Privalov. :alright:

I'm downloading a copy as I type. :)
Posted on 2001-11-20 07:38:01 by Eóin
Good Work. Do you work with Thomas?

SpAsm V.3.07 is out too... 10 times faster than FASM, and, when i take
a look FASM source, i wonder why... There must be some wrong stragegy
somewhere. The fact that SpAsm is faster is normal, because of the way
SpAsm encoder is written, but it should not be more than twice faster,
i think... At my feeling, it should only be a problem of the overall
organisation, not a problem of code quality.

Too: Very hard hang observed in the error Management of 'asmwork'. I
was just verifying the syntax of Data declarations and wrote a colon
after 'hinstance'. It hanged the whole system after the error Message
(K6/200/Win95).


Betov.
Posted on 2001-11-20 10:20:14 by Betov
The slowdown is because of macroinstructions (especially resource). Please compare how fast are assembled asmedit.asm (65143 bytes) and asmwork.asm (42346). The second one has a huge amount of macro uses.

In the fact fasm is still best for DOS programming, but I have signals some people very like "fasming" Win32 programs.

There is possibility to speed up this by making external resource compiler and built-in (accelerated) stdcall/invoke macros. The preprocessor should also be rewritten - this is the only part that never was optimized for speed (and remains almost unchanged from 0.9x versions).

And yes, asmwork is still extremelly buggy. I'll try to fix it, when I have time (probably no soon :( )
Posted on 2001-11-20 11:20:43 by Tomasz Grysztar
Sure that Macros are heavy time eaters. I was comparing with
a SpAsm source (always with much Macros). In SpAsm
compile time too, Macros eat about alf of the Compile
time.

You did not answer about: Do you work with Thomasz? or
are you Thomasz? I yes, i'll send you a mail...


Betov.
Posted on 2001-11-20 11:31:50 by Betov
Yes, I AM Tomasz Grysztar :)

One more thing about the speed: please remember fasm does multiple passes to align code (Needs 40 passes, when assembling itself! Horrible, my own program!).
Posted on 2001-11-20 11:48:19 by Tomasz Grysztar
Great job Privalov :alright:

You and Betov keep me from writteing my own Assembler every day ...

I also wonder how does my copy of TASM manage to take less than 1(one) second to assemble all HE game:and we have macros, 200.000lines of code, >1000 files in subdirs... (he makes only 4 passes)

i still wonder ...
Posted on 2001-11-20 18:12:16 by BogdanOntanu
This is absolutely impossible, Bodgan.
If you SEE this, this is because it does only partial re-compilations, only applying
on the tiny sub-thing you just modified.

I thought to, of implementing this in some way, but, with the
complexity of SpAsm on one hand,
and with the no end encreasing speed of processors, this
appeared to me to be not a great necessity. SpAsm would
rebuild your entire game, from scratch in about 20 seconds.
Well, i think this is short enough....

Betov.
Posted on 2001-11-21 03:06:52 by Betov
... I mean around 20 seconds on K6/200...

Also, the difficulty in re-compiling partial sources with SpAsm, (and
i suppose, with FASM too), is that they output the Applications (not .obj
to be linked). Not relying on a Linker makes partial compilations a bit
more difficult. An added difficulty for SpAsm is that is works on mono-
files Sources. But, the positive counter-parts of this difficulty are so
important and so many that the choice is easy, at my opinion.

I suppose you will agrea that Applications Sources bigger than 1 Mb are
not many around there, that more than 2 Mb should be difficult to find,
and that your 3 Mb and + one could be recorded in the World-Records-book.

SpAsm Source, actually is 1.85 Mb, but, frankly, this is just because i
want to offer the pretty simplicity of one stand alone Assembler to user,
(with zero installation...). But these 1.85 should better be considered
as a collection of tools than as one single tool... Choice problem for me,
but i prefer waiting 12 seconds at each compilation than breaking the use
simplicity.


Betov.

PS. Fodder, no need to debate about the mono-file choice. Be happy with
your thingye. :))
Posted on 2001-11-21 03:55:17 by Betov