LuxAsm questions

From: Frank Kotler (fbkotler_at_comcast.net)
Date: 06/22/04 

Date: Tue, 22 Jun 2004 09:09:00 GMT

snpphakel wrote:
 
> By the way, I have been following the 'LuxAsm' posts
> over here and I mean to ask, are you going to go through
> the standard C library or call the kernel directly via
> INT 80H ?

Current code uses int 80h. T.M.Sommers has raised some hard questions
about whether there's any "engineering" reason to prefer this. I
would've said "bloat". He says the libraries don't do anything that
wouldn't need to be done anyway. I would've said "my observation is that
doing it via int 80h is *much* smaller". But recent experiments with
Wilhelm Zadrapa's Nasm translation of one of Jonathan Bartlett's
examples yields (with the right command lines) a "helloworld" - calling
printf!!! - in 464 bytes. I'm impressed! I've underestimated the
potential of shared libraries. I personally still lean towards int 80h.
I like the idiom - probably only because I'm a "dos-head at heart" :)

T.M.Sommers *also* raises the question of whether it should be done at
all or not. "It" being "assembly apps" in Linux, not specifically LuxAsm
- but the question is especially relevant to LuxAsm, since it's
specifically designed (being designed) to encourage "this sort of
thing". Linux is a "system", and the design specs clearly state "Thou
Shalt Be Portable". Using asm where it isn't absolutely necessary is
outside of the design specs. This isn't just "the C religion" - Linux
actually *does* run on multiple architectures! I don't know if it's a
"brave revolutionary act" or a "tantrum by spoiled children", but it's
definitely against the rules!

When people suggest that Nasm should be re-written in Nasm, I say "Yeah,
that would be cool... but it wouldn't be Nasm." It may be impossible to
write asm apps for Linux. If we do, it violates the design
specification, and isn't Linux.

The counter argument to all this is "why should x86 users - a clear
majority - be deprived of better code just because the poor folks on SGI
can't run it?" (you'll notice that this assumes that "asm-written code
is better" - something we hope to demonstrate) I'm pretty determined to
"go for it" in this case, even if it "isn't really Linux".

> And will the assembler per se be text mode
> or is everything going to be 'X' based ? IMHO, making the
> assembler independant of X will be more flexible and
> attractive to die-hard CLI users.

What C (the developer, not the language) is currently coding is a
command line assembler. We're not going to throw it away. The idea is
that, once it'll assemble itself we'll use it to build the GUI interface
to itself. Current experiments with X end with "can't open display" if
it can't - I don't see why it couldn't run a command line version
instead. Being a die-fairly-hard CLI-guy myself, I can appreciate this
suggestion! It may be a "harder sell" to convince such a person to
switch to LuxAsm than someone who's looking for an...

> And is the IRADE,
> (Integrated Rapid Application Development Environment ;)

Ooooh! I *like* that! :)

> going to 'Xlib' based or will it depend on other toolkits
> like 'qt' 'gtk' etc, etc. ?

Not decided yet. Just to add some other choices to the mix,
C-the-developer has got the beginnings of a GUI library - written in
C-the-language. Christian Fowelin has an "Xlib replacement" in "libASM"
- written in asm. We *could* go the "int 80h all the way" route! On the
other extreme, we could use something like "wxwindows", which would
simplify porting to MS Windows (or ReactOS?), if anyone ever wanted to.
"Easy portability to MS Windows" isn't on our list of design criteria
right now - "this one's for Linux"... But that could still be
reconsidered.

I'm inclined to think that we'll probably settle on something fairly low
level - Xlib/xt/motif-ish - but it's open for discussion. To borrow
another of T.M.Sommers' analogies, this group of cabinetmakers has
decided they *wanna* select their own tree, cut it down, and saw and
mill the lumber. Or maybe we'll buy the lumber and just mill it
ourselves. We probably don't want to grow the tree from seed :) We're
aware that "kits" are available, and that if we use one it guarantees
that our cabinet will fit together with existing cabinetry. We know
we'll have to make sure that the parts that mate with existing cabinets
are of standard dimensions, but we want to be able to do it "free form"
from there. We know we could "do as the Romans", and get a disposable
plastic cabinet from CheapMart, but we want something a little more
"handmade" and specifically suited to its intended purpose.

You sound like you might have opinions on some of these questions. We'd
love to hear 'em!

Best,
Frank

Relevant Pages

  • Amish Furniture CAD design
    ... Can anyone suggest a good Computer Aided Design tool for cabinet ... and furniture design? ... VERY LITTLE about Linux, other than how to spell Linux, and have just ...
    (Fedora)
  • Re: New Mac user here
    ... Don't take a Linux advocate's word for anything. ... Gnome are the best GUIs in the world is hardly the same thing as taking ... Gnome will never achieve simplicity of design. ... Gnome is inept on every level, from the topmost layer, down to the programmer ...
    (comp.sys.mac.advocacy)
  • Re: New Mac user here
    ... Don't take a Linux advocate's word for anything. ... Gnome are the best GUIs in the world is hardly the same thing as taking ... Good design is about simplicity. ... programmer APIs and implementation. ...
    (comp.sys.mac.advocacy)
  • Re: Response a negative view about Delphi
    ... and in return they get free work from developers. ... developers help you at no cost, rather than hire them for high cost. ... The Linux project also doesn't run at all for most PC users. ... the end users count when it comes to judging design. ...
    (borland.public.delphi.non-technical)
  • Re: Report from the LuxAsm mailing list for Betov
    ... You will be able to use LuxAsm as a command-line tool - like any other - ... for use with, for example, "makefiles" and so forth...if the editor crashes ... I've thought of this...and it was a _DELIBRATE_ design decision ... the assembler's "assemble" service and then pass it source code and it'll ...
    (alt.lang.asm)