Re: LuxAsm Development Team

From: hutch-- (hutch_at_movsd.com)
Date: 02/02/04 

Date: 2 Feb 2004 02:30:56 -0800

Beth,

If I had one over-riding comment on a venture of the type you have in
mind, its DON'T follow a badly written piece of crippleware like
Betov's toy. Current win32 assemblers are about 1990 technology,
Betov's is 70s technology where what is needed especially in the linux
area is a 21st century tool that will do far more with additional
flexibility and facilities.

An assembler with optional high level constructions that were well
written instead of being tack ons would be a big start. Modular design
of code with full library support would make it a professional
extendible tool, some thought with the parser/scanner allows flexible
syntax and punctuation with a number of well understoof commenting
methods.

The more power and flexibility you can put into its design right from
the start, the longer it will last before needing a complete rewrite.
A "CAN DO" assembler is far more powerful than an ideologically
crippled assembler that hides its inadequacies behind rhetoric. Being
able to call any of the standard C libraries in LINUX would take a lot
of the hack work out of coding a linux app and if the facilities are
there to start with like IF blocks and SWITCH blocks among many
others, the tool would end up with a very wide audience.

Regards,

hutch at movsd dot com

" <BethStone21@hotmail.NOSPICEDHAM.com> wrote in message news:<i83Tb.85$O7.70@newsfep3-gui.server.ntli.net>...
> Randy wrote:
> > Some people cite efficiency as a reason for using assembly. In my
> > experience, however, the performance of assemblers is far more
> > related to the quality of the coding than the choice of language.
>
> Aye; But I know better than that: "algorithm is king" _always_...it
> doesn't hurt, mind you, to then code your perfect algorithm in
> assembly...but - without wanting to drag that other thread over here
> in any way - algorithm is top priority (which doesn't mean there
> aren't other priorities to consider...just that algorithm comes before
> language choice in that order ;)...
>
> Our "reason" for assembly over at LuxAsm is just that we were
> originally copying RosAsm, that takes that approach...and then it's a
> case of "why not?", even if we're no longer copying RosAsm
> anymore...which is the whole great "non-technical" case for why LuxAsm
> will be going down this route...
>
> Beth :)

Relevant Pages

  • Re: PIC Assembler.
    ... I can think of no reason whatever to use a language (assembler) that requires ... You can retract your sweeping, godlike statement, tell me ... possibilities you cannot and have not been able to imagine. ... Keep in mind that, for the most part, I am not expecting to convince ...
    (sci.electronics.basics)
  • Re: TASM, MASM etc
    ... its flexibility ... for easy way out, if i wanted to use printf i would use C, not asm. ... assembly doesn't mean you can't call decent library routines to handle ... Can you suggest a good assembler / linker for a 32 bit code which will ...
    (alt.lang.asm)
  • Re: Get HLA Training
    ... >> as the Demo that Beth wrote in HLA low Asm, in the past, ... >> Assembler, and you are done, fully, simpler, and cleaner. ... Mind you 2) a book based on HLA is, ... Macros Set, that fully implements the usual HLL Constructs, ...
    (alt.lang.asm)
  • Top Level Ultrasonic Assembler -- Security is Everything
    ... Assembler. ... The code is compatible with major architectures, ... security in mind and there might be prototypes of real hardware ...
    (alt.lang.asm)
  • Re: Nanotechnology "X Prize"
    ... > assembler. ... Or maybe you have in mind a different set of problems than I. ... You may have a different problem domain in mind since I'm not sure how ...
    (sci.nanotech)