Re: When to use Rosasm, when to use Masm?

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 03/04/05 

Date: Fri, 04 Mar 2005 09:48:59 GMT

Randy wrote:
> Beth writes:
> > It's not a great "advert" for assembly language coding when you might
> > suggest "you can use assembly language to reduce your code size and
speed
> > up your programs" when, umm, RosAsm is written in ASM and is really
rather
> > "bloated" at 3 megabytes considering what it does...it may illustrate
> > "fast" to a degree but not the most impressive example...
>
> Really, Beth, it depends entirely on what the code does.
> One person's bloat is another man's essential features...

True; Which might be why I put "considering what it does" as a qualifier...

And _am_ modifying the measure in terms of "how big it is _FOR WHAT IT
DOES_"...considering how large - as a "guestimate" - one would really need
to implement such features _in assembly language_ to the degree Rene has
done it and so forth...delibrately, this time, I'm trying NOT to make a
"value judgement" on those features, merely a judgement that if 3MB were
its true size (which it isn't in the rather "misleading" way Rene's been
trying to present it, as if all 3MB were actual binary code, not simply
"source code"...which is _always_ very typically far larger than the
binary...plus, of course, it's a very bad measure because have you, for
example, seen the size of Rene's comments for his macros? And that's being
included, even though it contributes nothing to the functionality at
all...and it's, indeed, not how many lines of code you've got but how well
coded they are...for example, with better macros and assembler features,
perhaps a lot of the code could have been simplified and reduced..."code
re-use" to further reduce that size...not that these things are in any way
"bad" - on the contrary - but it's completely "misleading" to use "lines of
source code" as anything but the roughest of rough measures because it's
not really a direct measure of anything particularly useful :)...

[ snip ]
> > Nevertheless, it's probably _GOOD FOR YOU_ that your little "cheating"
> > here
> > to pretend there's more code in RosAsm than there really is, has been
> > exposed...because 683KB is more reasonable (still seems a little
"bloated"
> > but if you've not really tried to make it small and have all those
> > "pre-parsers" built-in, that seems more reasonable a figure)...3.39MB
for
> > what RosAsm does would have been _BLOATWARE_, anyway...
>
> I can't speak for the rest of the RosAsm system, but given the paucity
> of features in the assembler, I can't understand why it consumes even
> as many as 10,000 lines of code (which is the number Rene through
> out at one time, IIRC).

Well, yes, this is what I meant by "bloatware" in this context...you phrase
it better than I...I meant it was "bloated" from the perspective, as you
say, that the features it does have don't seem to be strictly demanding the
amount we see...obviously, you _can_ write it that way but, you know,
"intuitively", it seems "rather large"...

It would be interesting to see how big each part individually is...as, for
example, Scartamil's "forms wizard" opens up its own window and is much an
"application in itself" (at least, it certainly will be once fully
completed...it's doing "Delphi's job" to a degree there, so I can see that
taking some bytes...but, currently, it's not completed - more like a
"placeholder" - so it shouldn't yet be taking that much :)...you know, how
much is really _RosAsm_ itself and not to do with "forms wizards" or
"pre-parsers" and such? Again, not a "value judgement" on those features
themselves because, in fact, the "forms wizard" and "pre-parsers" and such
are some of RosAsm's more interesting features...but just a case of "how
much is each individual part contributing to that source code / file
size?", out of interest to see what's what...you know, perhaps, indeed,
RosAsm itself - the _assembler_ part in isolation - isn't really even
taking 10,000 lines of code...but because it's all jumbled up inside the
one EXE file, all the various components contribute to the figure...

> > That whole "*** size contest" thing really does warp men's minds,
doesn't
> > it? "Use assembly! You can make small, fast programs with assembly!" /
> "and
> > you say RosAsm is written in assembly?" / "Yes...look how big it is!
It's
> > massive! It's 3MB massive! Look how big my ***...sorry, I mean: Look
how
> > big my assembler is!! 3MB! See my 3MB and fear me, puny
mortal!!"...*user
> > walks off unimpressed by yet another logical contradiction from
Rene*...
>
> If that 3MB was actually 3MB and it was all doing something useful, yes,
> it would be impressive. But as you point out, given the paucity of
features
> in the assembler, the size of the source file would be a scandal.

Yeah, my line of thinking...

> Again, I've no idea what is needed to support his IDE, disassembler,
> debugger, etc., so I'll not comment any further on that.

It's not Microsoft "scandalous" but careful, efficient, well-structured
_assembly code_ really shouldn't be quite so big...even if not being "size
contest" obsessive about every byte, it still seems too big...

Consider, for example, something like MenuetOS - also written completely in
ASM - that is _AN COMPLETE OPERATING SYSTEM_ (plus applications for that
OS)...just downloaded the "kernel sources" ZIP file straight from the
website and that's 798KB of _source code_ (which even includes the ".bat"
batch file for compiling it)...

Even looking at the "source code" ZIP for the Menuet applications (which,
by the way, includes things like an MP3 file for the "intro" sound when it
loads up...bitmap files for the default desktop background and icons and
even bitmaps for the "chess" game that's included :), this amounts to
1.45MB of _source code_...and you're getting chess games, HTTP / NNTP /
DHCP / HTTPS / Telnet / etc. stuff, paint package, Tetris game, text
editor, terminal, JPEG support, MP3 stuff, PCI stuff and even its own
development package stuff too...taking _SOLELY_ the files ending with
".asm" or ".inc", that's 983KB of source code...

And, you know, this is a working GUI _operating system_ here...it's not
merely "calling" some Windows API to do its work, it is _implementing it
from the ground up_...and, applications included (bringing it to about 2MB
of "source code"...comparable but still smaller than RosAsm's source code),
it's got to be providing more "features" than RosAsm does and these are
_complete_ "features"...that is to say, this isn't merely calling an "API"
to render a window, this _includes_ the actual kernel / shell OS code to
_implement_ that window _AS WELL_...being an operating system, it's not
"using API", it's _IMPLEMENTING_ API...and all those applications (some of
which are comparable development tools themselves: Paint package, text
editor, etc. :)...but it is _STILL_ weighing in - even at "source code"
metrics - as _LESS_ than RosAsm does...

Or shall we ask wolfgang how big his _opearating system_ weighs in at?

These are doing far more with more "features" and are _implementing it from
the ground up_ and they _still_ ain't as "bloated" as RosAsm with
incomplete features that only has to _call_ Windows API, not _implement_
the things as well...

True, it's not Microsoft "scandalous"...it's not in their league of
"bloatware"...but this doesn't "intuitively" seem "good" either...things,
in assembly language, doing an awful lot more (complete OSes with a full
set of applications included), weigh in much less than RosAsm does with its
many "incomplete" features...

> > First: Use _COMPRESSION_ on the "embedded source code"...raw ASCII is
> > "bloating" these files to large sizes unnecessarily...be careful with
> > compression, of course, from the perspective that they are all
"patented"
>
> Wrong. The UNISYS patent ran out last year.
> Yep, good thing about patents, they do expire after a while.

Well, I was being "general" there, obviously...didn't mention UNISYS
anywhere...

In fact, I point out "ZLIB" which doesn't have a "patent" on it, so,
obviously, that's a "colloquial all" rather than a "literal all" there...

Oh, okay, "most" are patented..."almost all" are patented...happy now? ;)

> > everyone...but, note, "ZLIB" (ignore the "lib" in the name...it's
normally
> > distributed as a library but you can get it as a DLL or can look at the
> > source code to "lift" the algorithm to code it yourself in ASM :) is a
> > nice compression technology, designed to be "free" and that means
> > "patent free" as much as anything else :)...
>
> And given Rene's inability to solve problems with his symbol table
design,
> the last thing I'd wish on the RosAsm user base is for him to use
> compression on the source files. Talk about people losing work! It's
> already a precarious situation with RosAsm crashing and losing work in
> progress. Imagine a bug in the decompression algorithm causing people
> to lose all their work. :-(

Well, yes...there is that possibility but I was exercising "innocent until
proven guilty" there, so to speak...presuming that Rene would implement it
properly...

After all, doesn't the same basic concept, as you indirectly point out,
apply to pretty much _anywhere_ in a piece of software? That is, if the
"forms wizard" crashes before you save your work, you could lose it...if
the "about" dialogue box even, were to crash then work could be lost...

Simply, the program shouldn't crash anywhere, as best as we're able,
because a crash when the "work in progress" is in RAM will mean "lost
work", wherever that crash happens in the program...

Anyway, he need not use "compression" specifically...I presume RosAsm
"tokenises" source code like most assemblers / compilers do (though I've
not specifically looked to see :)...well, there's a means to reduce the
size right there without going near an actual proper "compression
algorithm"...don't store the ASCII source code, store the "tokens" instead
(plus, some "additional information" for restoring it exactly - or near
enough - to how the programmer typed it..."comments" and such can remain
"as is")...that would make a marked difference to the "file size" but
wouldn't be anything that, presuming "typical compiler structure" to
RosAsm's assembly process (which might be presuming too far but would be
applicable to most other tools, anyway ;), would be that difficult to
implement...

Indeed, couple it with what I was saying about starting to process the
source code in the editor "early" and it all fits together quite neatly, I
reckon...the programmer types in the source code, RosAsm can at least
"tokenise" this there and then...the "tokens" are what are stored in the
"embedded source code", the "tokens" are what is fed onto the assembly
process and so forth...and just have it that the editor "unravels" this
tokenised form for display to the programmer (so, the programmer only ever
sees their source code and doesn't need to know or is effected by the fact
that it's in a more compact "token" form internally)...this also fits in to
the fact that only the RosAsm IDE can read out that "embedded source code",
anyway...

Plus, if Rene wants to speed up his "assembly speed" - without using
dangerously unstable "look-up" algorithms - then this is a simple and
effective method...get the source code "pre-parsed" (at least, that's what
Rene would probably call it ;) as it is typed into the editor...not quite
as "exotic" as what LuxAsm will do - only "half the story" of the fuller
"incremental assembly" that we have planned - but it's still something
RosAsm could easily do that would reduce that "embedded source code" and
would speed up the "assemble speed" (because none of the time would be
spent on "tokenising", just on the processing itself)...I've said it to
Rene many times: He actually has the "jump" on everyone to be able to
implement this kind of thing first because, of course, he's already got the
perfect tool coded where this entirely fits in (surprises me, sort of, that
Rene hasn't already thought of it and coded something like it), as it has
the IDE and the "embedded source code" which would be the components
necessary to get it going...but he prefers this "assembler with an IDE
stuck onto it"...it seems a rather "disappointing" use of a GUI
front-end...you know, _IF_ you're going to have the assembler and editor
all in the same executable - if that's your design - then, please,
_EXPLOIT_ that design and properly _integrate_ the two to provide the
programmer with a much better tool...it assembles quicker and produces
smaller files with "embedded source code" and, yet, from the programmer's
perspective, it appears no different whatsoever to how it already works...

> > > Facts are facts. You don't like facts. Your problem.
> >
> > On the contrary, Mr.Tournois...you are the one who's boldly claimed for
> > months this "RosAsm is 3 Megabytes!" claim, when the _FACT_ is that
RosAsm
> > is 683KB of actual code and the rest is just _uncompressed_ source code
> > embedded in the EXE...
>
> Well, we all know what "facts" means in Betovspeak :-)

Indeed...

> > But it's interesting to look at the other stuff...the "threads: 1", of
> > course, means you've not coding RosAsm as a "multi-threaded"
> > application...well, that's reasonable enough...though, of course, you
> could
> > always launch a second thread that could "background process" the
source
> > code in the editor...then, when the user hits "assemble", you could
have
> > _already_ processed at least things like "tokenising" and that kind of
> > thing...this would then be "taken off" your "assemble speed" and would
> make
> > RosAsm faster again (and it's a "trick" that neither HLA nor MASM or
any
> > other non-IDE assembler can match...they _have to_ process it all in
one
> > go...with RosAsm, you can get yourself a "head start" by at least
> beginning
> > to process the code in the editor even before the "assemble" button is
> > pressed...it needn't be as "extreme" as LuxAsm "incremental
> > compilation"...for example, you could at least run through the source
code
> > in the "background process" to start "tokenising" it and doing the
basic
> > "pre-processing" kind of stuff :)...
>
> You're not entirely correct. With HLA, MASM, FASM, or whatever,
> I can break my large project into a series of smaller files (that compile
> separately) and run a parallel make on them. Something that is not
> possible with a monolithic application like RosAsm. And this is all
> achievable without any special coding on the part of HLA, FASM, whatever.
> There *are* benefits to command-line tools, you know?

Yeah, true enough...

After all, the "GUI / command-line" name is just "symbolic" because that
only refers to the user interface style...of course, _IF_ the command-line
is used in the same "parallel" way then that's equally as good and "user
interface" has nothing to do with it...

But, as I say, it's "symbolic"..."command-line" _typically_ means "batch
files" and such, where it's all done "serially", one after the other...BUT,
if you're using some "parallel make" then that would "rectify" the
situation...

But, well, hands up who actually regularly uses some "parallel make"
utility...yeah, I thought as much...

But, yeah, _IF_ you're using something like that, then that _would_ be
"roughly equivalent" so the argument would not apply...okay, it's "sloppy
language" to call it "command-line" because that's associating the "user
interface style" with the way it operates...and that "link" is always
there, just a "convention" that "command-line" typically means "serial"...

Indeed, one example of a compiler that _DOES_ do the kind of "pre-process
the tokens ahead of time via the editor" thing that I'm talking about is,
in fact, a DOS application: The QuickBASIC compiler...

That's how it manages to be "quicker" than all the rest, you see: It's kind
of "cheating"...when you type stuff in, it gets to work in _compiling_ it
there and then (up to a point, anyway)...as it does much of the work at
that point, when you hit the "RUN" option, it starts almost immediately,
giving an impression that it's "interpreted", not compiled...or, at least,
by _TAKING ADVANTAGE_ of having a "built-in editor" that it can "start
early" on processing the source code, it can have it "compiled in the
background" (or, at least, "mostly so"...at the very least, you can do
"pre-tokenising" or something ;)...and then it has "compiled" performance
but "interpreted" ease-of-use...you hit "RUN" and it more or less starts
immediately, just as if it were "interpreted"...and it has the "immediate"
window for typing commands directly and interprets errors in the right
places and such, so it really gives the _impression_ of being "interpreted"
but it's actually a compiler (in the main...this is BASIC, after
all...quite a degree, no doubt, of "call pre-written routines" is what it
mostly compiles down to anyway :)...

So, yeah, this _IS_ possible in a "command-line" or "text-based" or
"single-tasking" environment _IF_ it's using "parallel make" or being
"co-operative multi-tasking" in how it does the "background processing" and
so on and so forth...true enough, "command line" is the wrong peg to hang
it on...but you Hopefully know what I mean...

Beth :)