Slashdot Mirror

If there is anything that I have learned in the past 10 years of writing code (since before high school), I have learned that the following sequence of learning is ideal.
1. HTML/CSS/JavaScript - Get acquainted with web programming. None of that Nambly-pambly BBCode crap that they offer on MySpace.
2. Python - I wish I had got into this before I learned C++. Good for learning about shells if you decide to switch to Linux or BSD, especially if you decide to create your own website through a webhosting provider that uses SSH.
3. C/C++ and/or PHP/MySQL. - Playing with the big-boy toys at this point. The safety net that points 1 and 2 provided has been lowered.
4. OpenGL or Assembly Programming. - Really advanced programming! OpenGL is high-level. Assembly is low-level.
From there on, the sky is the limit.

I have legacy code that depends on ebx being preserved across system calls.

See the changlog. I am (JH).

The ABI doesn't matter all that much to you, even if you have to compile code yourself and use the prescribed compiler version. This is important when you are programming assembly, which you have already ruled out with your comment.

In case you actually want to learn something new have a look at this:
http://www.caldera.com/developers/devspecs/

or this to get an overview:
http://www.linuxassembly.org/

You may have figured out by now that ABI means Application Binary Interface (How come you didn't write about it in the article?). As a user you run into trouble mainly when two compilers have to live together on one system, and they support a different ABI.

See here for an example:

http://lists.debian.org/debian-release/2005/04/msg 00153.html

While all those changes may seem a nuisance to you, this may just be the thing some people are willing to accept to get some benefits out of not having to carry along the remnants of a legacy architecture.

If that's not what you want then Windows may just be the thing for you. To say that Linux developers have failed is maybe a sign of a somewhat overboarding sense of self-importance. Don't forget, that those people frequently write the code for fun or to scratch an itch, if they are happy they certainly haven't failed.

... of code morphing under Linux, using assembly can be found here. The imagination runs wild...

There is also asmutils httpd

Want it small?

How about some utils which are written in assembly and are not dependent upon other libs? They're faster and smaller. You may want to look at LinuxAssembly.org's asm utils. They say it works for FreeBSD and other BSDs, though I haven't tested this myself (yet). When I tried them in Linux a few years ago, they weren't quite complete, but being small and independent has its advantages. When it's complete (maybe it is now?), I imagine these programs will be the choice for those who want to save disk space or speed up their system. Such a project would work in C. If it was in C, it would probably get more developers on board too...

It's good that they are trying to save disk space, but why don't they just rewrite them so they don't use libc? Linux assembly.org is working on such a project, though it doesn't have to be in assembly. I've done some work using direct syscalls in Linux with C (look at /usr/include/asm--start with unistd.h). I haven't looked at FreeBSD in this way yet, but I think it can be done. At the very least, simple utilities like cp and ln could be written this way. Save disk space and be staticly linked--good all the way around.

What, like the one here?

Do you mean write the entire OS in assembly? There are a couple of projects that use Linux Assembly's mini distribution of tools coded in 100% asm for space reasons but I'm not sure if writing the entire kernel in asm would be practical.
Oh wait...

So if it is, then why can't the separate-but-equal approach be applied to BusyBox, why haven't the developers chosen a less monolithic solution? Seriously, I fail to realize how one large file can be effectively different than dozens of small, efficiently-optimized binutils. Heck, if I wasn't so busy cybering I'd put in some #defines in the GNU binutils and fileutils packages to allow a less-saturated-fat version to be compiled, all directly from the same source.

On a similiar note, has anyone taken up the project of transcoding BusyBox into Unix or Linux assembly language? GCC can do a damn good job of optimizing out loops, but you can't beat hand-coded assembly in terms of space.

I think there are quite a few. It's seen as a challenge, and does have practical uses. Have a look at Toms Rootboot disk - it includes a web server, a telnet server, a telnet client, an nfs client, wget, gzip, bzip2, vi, a whole load of network drivers, and a tonne of other stuff, all compressed down onto one floppy disk. Only I've never quite been able to find the source code for any of it despite spending a small amount of time looking - possibly someone would be able to put me right on that one.

There are also lots of interesting articles on linuxassembly.org.

Andrew

I think there are quite a few. It's seen as a challenge, and does have practical uses. Have a look at Toms Rootboot disk - it includes a web server, a telnet server, a telnet client, an nfs client, wget, gzip, bzip2, vi, a whole load of network drivers, and a tonne of other stuff, all compressed down onto one floppy disk. Only I've never quite been able to find the source code for any of it despite spending a small amount of time looking - possibly someone would be able to put me right on that one.

There are also lots of interesting articles on linuxassembly.org.

Andrew

If you're in Linuxland, you might find linuxassembly.org helpful. I've done some assembly before (only a semester's worth, though), and the site was rather useful to me. If you've never done x86, though, there might not be enough there for you . . .

There is a project at http://linuxassembly.org/asmutils.html where they're writing some of the standard UNIX utilities in x86 assembly. It's used for things like floppy distributions such as tomsrtbt.

I used to do some assembly back in the DOS days and keep meaning to have a look again sometime.

But those people could jmp along to :

• http://www.linuxassembly.org/

LinuxAssembly - go here - also has an almost complete set of replacements for common GNU and bash utilities. There's some nice bonuses as well - the world's smallest Web server and some tiny graphics apps for the framebuffer.

Go to http://linuxassembly.org and look at the asmutils package. That Konstantin is one mighty assembler wizard.

At the asmutils page. 586 bytes standalone executable. Make that!

Best regards,
The Anonymous Coward from Estern Europe