[ale] why not asm

John Mills jmmills at telocity.com
Thu Dec 20 09:52:14 EST 2001


Hi, Stephen -

On Wed, 19 Dec 2001, Stephen Turner wrote:

> yea so you would code a vcr or car in asm but still..
> so its potentially a pain in the rear..  its smaller
> its faster and its cleaner ...

By no means sure with a large amount of code and today's RISC processors.
Compiler optimization now includes instruction scheduling to take
advantage of processor pipelining, and that effort only needs to be spent
once - in building the compiler - rather than each time you set pass data
and call a different type of subroutine.

> seems to me if a os
> such as linux could be beat it would be through
> this... i mean if ya wanna have a hobby program a os
> in c if ya wanna get serious about an os ya do it in
> assembly..

There is always a trade-off between the number of people and hours
available vs. resources used. Computer resources get cheaper by the day,
remember, and you have more and more of them to manage in the average
computer as a consequence/opportunity.


> yea ok.. its gonna need an over haul to be
> compatible with diff chips.. thats a prob but think of
> how sweet linux would be in assembly? how fast? how
> clean? how small!

How few processors it would run on! what limited hardware it would
support!

Linux now runs on targets from IBM system-370s to embedded StrongARM
controllers. Historically, portability has been a much more important
asset for computer hardware and software than efficiency or techinical
superiority. (Naturally market penetration can overcome this - as in
MsWin.)

> it would truely be the best os in
> the land but then perhaps im just a crazy nut with too
> much time on his hands hopeing to take a impossible
> task by the horns someday? as the saying goes if you
> wanna win you have to grab the bull by the balz ;) ohh
> how sweet it would be though!

You're giving up a lot of present functionality to achieve it, and I think
it's a step backwards achieved at a huge expenditure of effort.

The rule of thumb is "a few percent of your code is responsible for the
vast majority of improvable inefficiency." This means you are better off
to write your code [in high level languages], profile it, and spend your
effort on those few places where you are getting the _vast_ majority of
your performance hits.

But Hey - do it and open-source it.

-- 
Regards -
 John Mills


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.






More information about the Ale mailing list