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

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

  • Next message: Frank Kotler: "Re: stricmp" 
    Date: Thu, 10 Mar 2005 02:28:23 GMT

    Arargh wrote:
    > Randy wrote:
    > <snip>
    > >You could create an editor/IDE that tokenizes source files as it reads
    them,
    > >and detokenizes the output when saving files (and when displaying them,
    > >of course), But I'm not sure I'd see the benefit. From a space point of
    >
    > AFAIK, that's exactly what QBasic and the QuickBasic editors do.

    Yeah, that's one of the examples of this in practice that I pointed to
    before...

    Anyway, I think there's a degree of "lack of imagination" here...after all,
    just because we are tokenising for the editor and assembler whilst running
    doesn't actually mean that it can't be _de-tokenised_ stuff saved to the
    disk...

    Because, in fact, if you take a look at how QuickBASIC works then it does
    "tokenise" but, in the "save" options, there's the option of choosing "fast
    load / save" or "plain text"...so, if you want it plain text for other
    editors then you can choose "plain text" as the output...there, problem
    solved...

    Also, Randy criticised the idea _GENERICALLY_ but, of course, I was talking
    about a _SPECIFIC_ instance with Rene's RosAsm...that is, RosAsm saves
    "source code in the executable"...as you've pointed out, this format is
    _ONLY_ understood by RosAsm (and "SourceKiller"), anyway...hence, "in for a
    penny, in for a pound" (as we like to say over here...convert to cents and
    dollars or Euros, as desired ;)...once the format can only possibly be read
    by RosAsm, then "the deed is done"...there is no additional problem that
    the source code is saved tokenised or not...it's RosAsm's _OWN_ format, so
    Rene can define it to be whatever Rene wants it to be (including, of
    course, completely ignoring my suggestions and sticking with plain
    ASCII...I'm only "suggesting" and explaining why I think it's a great
    idea...it's Rene's decision, though, of course :)...

    Regards the tokenising "tidying up" the code...well, that's a nice
    potential "feature" to _let_ this happen, when the user chooses the
    "option" for that...QuickBASIC does similar (for example, when you type the
    name of a variable with different case, it automatically converts all other
    instances of that variable throughout the program to have the same
    case...an interesting approach to "case insensitivity" but where it
    automatically does a "tidy up" and changes all instances of that variable
    to the same case, so it is always _consistent_ throughout the program while
    being "insensitive" at the same time)...

    BUT, if you want it to not "re-format" everything, then "additional
    information" can also be retained, which preserve formatting information to
    be able to restore it to _exactly_ what was typed...an extra byte, for
    example, could store the "case" for up to 8 characters and be used to
    restore it exactly as typed (e.g. "MoV" gets turned into some "token" for
    "mov" plus three bits in some additional byte could hold "101" to remember
    the case for each character...this allows it to be restored to exactly how
    it was typed - the amount of tabs and spaces stored too so that the
    positioning is the same, comments stored exactly "as is" and so forth - but
    is still more efficient storage...which is neatly separated between what's
    "tokens" and what's just cosmetic "formatting"...and, of course, only the
    "tokens" are bothered with by the assembler part, the "formatting"
    information is just for displaying it all to the user, exactly as typed,
    that, indeed, they could have _NO IDEA_ what's going on behind the scenes
    :)...

    Plus, what exactly stops _BOTH_ from happening simultaneously?

    That is, you use the editor to edit your source code files...these are
    saved in "plain text" to "*.asm" or "*.inc" files, in the usual way, so
    your _source_ files are, indeed, "plain text", appropriate for other
    editors...but, for the "source code in the output" (I say "output" rather
    than "executable" here because, more generically, you could pop "embedded
    source code" into library files too, propogating it along :) feature, it's
    the _tokens_ which go into that file...if the output file is lying around,
    then the editor can pick that up to "save time" (kind of like "pre-compiled
    headers", really :)...if it's not, then it can load and process the plain
    text file, as it loads (and then put that into the "output file" for next
    time)...the _SOURCE_ remains "plain text" so is perfectly appropriate for
    other editors...the "tokens" - a bit like MAKE looking for object code
    files - can be loaded, if present...if not, process it to get the "tokens"
    and that can be saved (so, next time, they will be there :)...

    Indeed, all very much dealt with as "pre-compiled headers" are dealt with
    by most HLLs already...do you want to tell me that this is "not going to
    work" when nearly all modern C / C++, Pascal and other compilers all now
    tend to make automatic use of _EXACTLY_ this kind of feature? Well, why
    should HLLs have all the "fun"? This is an aspect that's to do with
    "implementation", not with "high-level / low-level" considerations...you
    know, about file formats and how we load and save things...nothing to do
    with the language itself...so, there seems to be no reason why this would
    be "anti-assembly" to simply _make use_ of your editor to speed along
    assembly and reduce the size of "source code in executable" stuff (yes,
    yes...I know _YOU_ don't want this feature, Randy...BUT Rene does...so if
    he's going to have it, the "damage", as you see it being, is _ALREADY
    DONE_...best that, if the feature is going to be there, that it is done
    _EFFICIENTLY_ and _WELL_, nicht wahr? ;)...

    It very much can work because, basically, it _already does_...QuickBASIC
    already does the "tokenising" thing...C / C++ compilers already do the
    "pre-compiled headers" thing (which also demonstrates the idea of "both at
    the same time" in that "pre-compiled headers" create _NEW FILES_ with the
    "pre-compiled" information and, thus, the original "plain text" can exist
    as it always did, suitable for "other editors"...and when "save" is
    selected, you simply save "plain text" back to the source file and save
    "tokens" to the output file...when I select "pre-compiled headers" in my
    C++ compiler and run it over, say, "windows.h", it doesn't transform that
    file into binary gibberish...it creates a _new file_ for the binary
    gibberish, leaving the original source alone...and then the compiler simply
    has a "if 'binary gibberish' file is also present, load it...if not,
    process plain text file into binary gibberish and _create_ this file"
    policy...and then the editor knows to save all the changes to _both_ files
    (plain text back to the source code file, as per what you'd naturally
    expect a source code editor to do...and the "tokenised" stuff into the
    "binary gibberish" file...which could be "embedded" in the output or could
    even be a separate file, like Microsoft now like to do with a _separate_
    "debugging info" file :)...

    There, problem solved...and it will work because it _DOES_ work...this is
    not "new idea" itself, you see, but merely "new application for old
    idea"...let an _assembler_ benefit from this kind of thing for once...

    Oh, also, I think you mentioned Randy that for the small amount it saves in
    time, is it worth it? Well, let us remember that this process could and
    should work "incrementally" (no, not necessarily "incremental assembly"
    itself but the way the files and such are dealt with can be
    "increment")...hence, just like the "object code files" you trumpet as
    being "good" to Rene - which operate by the _exact same principle_ - then,
    once the "binary gibberish" file is created, it is simply _loaded_ for
    every assembly after that..."incremental" can also be seen as the
    philosophy of "process _ONCE_ only"...

    So, like object code files and MAKE, once the files have been created, then
    there's no need to "re-process" the entire assembly file over and over...if
    no changes have been made to a particular file, then the current "binary
    gibberish" file is still applicable...load that and save yourself a chunk
    of processing time...

    And, with LuxAsm, the "extension" here is that, of course, the assembler
    operates "incrementally"...hence, even when you do make changes to a file,
    it, again, follows "process _ONCE_ only"...just those changes are processed
    and "merged" with what is currently already in the file...

    So, something like this:

    +--+ +--------+-+ +--+
    | |\ |########|X| ----- save -----> | |\
    | +-+ --- load ---> +--------+-+ & | +-+
    | | | | --- assemble ---> | |
    | | <--- save --- | | | |
    +----+ +----------+ <---- load ------ +----+
    Source Assembler / IDE Output

    Note, that "load" can also grab the "tokenised" form from the output file
    (when present)...and that the "save" operation saves in _BOTH_ directions,
    so plain text goes back into the source, as usual, but the "tokens" can go
    into the "output" file (and I say "output file" because, though RosAsm is
    only interested in ".exe" and ".dll", you could, of course, make the
    process more "generic" that it can also pop such information into ".obj"
    and ".lib" files...I mean, both PE format and ELF on Linux have "object
    code" formats that are nearly the asme as their "exectuable" formats
    (executables just having extra "header information" for executable but
    lacking the "extra info" in object files for relocations, debugging and so
    forth...which, of course, can simply have "source code" added as another
    set of information - just like debugging information or "comments", so
    other tools should _ignore_ this at worst - to the file :)...

    Go on, feel free..."invent" more problems that don't actually
    exist...programmers _are_ problem solvers, at their core...I _LIKE_ a good
    challenge in trying to work out how to make what everyone thinks is
    "impossible" quite, quite _possible_...

    LuxAsm _WILL_ be incorporating these features ("embedding source code",
    though, is _OPTIONAL_ in LuxAsm...in reverse to RosAsm - which
    automatically includes and then you need to use "SourceKiller" to remove
    the source - the "source code" is only included on _REQUEST_...one
    personally Hopes that the feature will be used but there's is no
    "forcing"...both "open source" and "closed source" are _WELCOME_...in fact,
    as per "clause 5" and "clause 6" of the "open source definition" to not
    prejudice against individuals or corporations, nor to prejudice against
    particular uses being made from the software...both clauses that Rene
    _violates_ in the entire "raison d'etre" of RosAsm that his "open source"
    claim is just as dodgy as his "it's for ReactOS, not Windows" claim
    ;)...yet it _will_ have "library support"...yet it _will_ allow source code
    to be edited in other editors (though why anyone thinks "vi" is any good,
    is a mystery that's always been beyond my puny mortal understanding, I
    confess ;)..yet it _will_ kick arse out of "assembly speeds" because, in
    short, it only ever processes anything _ONCE_ and does most of that "in
    parallel" that you don't even see it do it...yet it will provide "feedback"
    to the programmer as they program and provide a "seamless development"
    philosophy throughout...

    And, yeah, both C and me use "asserts" (they are already in C's NASM "first
    version")...yet we all think NASM syntax is _better_ than MASM syntax...and
    if you really think MASM or any other assembler at the moment is
    "appropriate for large-scale work" then, sorry, there seems to be a "lack
    of imagination" error and a difference of opinion on what counts as
    _PROPER_ support for "large-scale" work...heck, if you're a minor genius
    with a lot of time to waste on your hands then it's _possible_ to do
    "large-scale work" using DEBUG, for Pete's sake...but this would NOT really
    be "proper support" for it, would it?

    Basically, have your little "wars", if you like, but the rest of us are
    perfectly capable of making up our own minds...play "philosophy" or
    "academic" all you like, I'm going for _pragmatism_, not "religion"...and,
    well, may the best woman win, she says without any "bias" at all ;)...

    Beth :)

  • Next message: Frank Kotler: "Re: stricmp"
    • Quantcast