Re: The Case Against RosAsm (#6)

From: Al (opcodeac_at_3*&hotmail.com)
Date: 01/15/04 

Date: Thu, 15 Jan 2004 08:35:49 GMT

Personally, I once tried the monolithic approach with a major project.
I've written about this in a few previous posts, but to make a long
story short I wrote a win32 NASM screensaver that was supposed to
display 3x3 rows of images. It would find these images in a folder.
Anyway, 5 months down the road, the source got so huge that it became
unwieldly. I'd have to keep scrolling up and down, I lost track of what
various routines did and it was a real headache keeping track of how the
earlier routines in the source code had affected the operations of the
later code. I'd have to admit my software engineering had really sucked,
but the monolithic approach sure exacerbated it.

I used to wonder why people split up their source code in various source
code files. After that major project (which really only reached the
alpha stage), I learned my lesson big time. In fact, if I were to go
back to that source code and try to work with it again, I'd may as well
re-write the darned thing!

Randall Hyde wrote:
> RosAsm Doesn't Do Libraries
>
> Without question, this is RosAsm's
> number one flaw. It doesn't support the
> ability to statically link in
> separately compiled object modules.
> Rene passes this off as some *great*
> feature of RosAsm. He seems to think
> that the "right" way to code in
> assembly is to write "monolithic"
> applications (all the source code to an
> application in one source file).
> Breaking source code up into separately
> compiled modules is heresy to Rene.
>
> The really funny part is that all the
> other assemblers, that *do* support
> separately compiled modules and
> linking, *also* support the creation of
> monolithic applications, should the
> programmer so desire to work that way.
> So it's not like you can do anything
> special because RosAsm *doesn't*
> support libaries. OTOH, you can do
> *lots* of things with those other
> assemblers that you *can't* do with
> RosAsm because it doesn't support
> libraries.
>
> The truth of the matter is that Rene
> probably doesn't have a *clue* how to
> implement static linking. The design of
> RosAsm (that buries source code into
> the EXE file) makes the whole concept
> of libraries foreign to his system.
> Rather than admit his product has a
> design flaw, he goes on and on about
> how "real" assemblers don't need a
> linker.
>
> He tries to use the tired argument that
> "RosAsm is so fast that it can assemble
> the entire source file fast enough that
> you don't need to use separate
> compilation." Of course, he fails to
> realize that most people use separate
> compilation for other reasons than
> speed these days (e.g., good software
> engineering practice).
>
> Today, most major assemblers not only
> provide linking/separate compilation
> facilities, but their users are
> actively developing "standard
> libraries" containing shared code (this
> includes HLA, MASM32, FASM, and other
> assemblers). Though RosAsm users can
> "cut & paste" sample code from other
> applications into their source files,
> the fact is that libraries are much
> easier to use and the lack of their
> support in RosAsm is a big determent to
> the RosAsm user.
>
> You've got to ask yourself, when
> considering which assembler to use: "Do
> I really want to get stuck using an
> assembler that doesn't support separate
> compilation and the linking of library
> modules?" Even if you don't think
> you'll be a big library user right
> away, consider what happens when your
> skills increase. Do you want to take
> the chance on being stuck with an
> assembler that won't grow with you?
>
> Cheers,
> Randy Hyde
>
>
>

Relevant Pages

  • Re: RosAsm is a broken pile of crap
    ... RosAsm can do with "cut & paste" can be done by every other assembler, ... All he is doing by not supporting statically linked libraries is ... *had* the source code to the library so you could add the comments, ...
    (alt.lang.asm)
  • Re: pgm object/source comparison
    ... There may be plenty of reasons why compilation fails, ... ILE, like default activation groups, objects ... I moved the libraries, files and ... >>> seems fairly obvious that the source code in those two don't match ...
    (comp.sys.ibm.as400.misc)
  • Re: Stack frames
    ... in order to save from no end Compilation ... Fast assemblers (RosAsm included) work great ... libraries, as it is practically impossible to do a large ... the only assembler anyone is trying to push as a serious ...
    (alt.lang.asm)
  • The Case Against RosAsm (#6)
    ... RosAsm Doesn't Do Libraries ... It doesn't support the ... compilation for other reasons than ...
    (alt.lang.asm)
  • Re: deciphering gprof (profiling) output
    ... You have already had a suggestion about using the debugger to find out where ... this is called in the compilation of your source code. ... libraries. ...
    (comp.lang.fortran)