I am using Linux as a firewall for my cable modem and have yet to see even a 5% load on my 486 box with only 32MB of memory and 300MB drive. Does it matter if BSD uses half as much processor
as the Linux install if the box sits 95% idle under full load now?
I'm using a Linux 486 box presently myself. I want / need more services on that box though.
Load isn't an issue at all. Security holes are the main gripe. Typically, I like to run telnet (grr... I'm stuck with a couple places I can only telnet from, not ssh from), httpd, and squid, among other things. (At least telnetd is wrapped with a TCP wrapper so only a couple hosts can connect.)
I also would like to run (but am rightfully afraid to) FTPD as it makes sharing files much easier. (I have some friends whose http proxy won't let them download files with certain extensions -- eg. mp3 -- but they can FTP just fine.) Every time I see a RH Linux advisory, I cringe.
Right now, I feel I'm reasonably secure as long
as I don't enable sendmail, and keep FTPD turned off. Apache will be the same regardless of OS.
SSHD doesn't change really, either. So, the OS doesn't matter too much. But still, with that many services running, it's tempting to use an OS whose goal is to be stable, correct, and by extension, secure. Linux simply lacks that maniacal focus.
FWIW, that machine still has Linux on it though.
That whole inertia thing.:-)
while the crux of the issue are BSD users (such as myself) saying that BSD is too comfortable for small tasks, and every day
wear, while Linux users say that BSD isn't.
BSD users find BSD comfortable. What a news flash! Every day, I interact with a Solaris machine (at work), a Linux machine (at home), and a BSDi (at my ISP). As long as I set my shell to bash and have the GNU utils override the defaults where possible, I don't notice much of a difference between the three. There's the occasional nit, though, and I have fewer of them on Linux. Also, I don't need to install GNU utils to override the defaults there.
So, for me (and it really is me that matters most when picking an OS for my desktop box), Linux is the right choice. For my friend down the hall from me, FreeBSD was the right choice for him for his desktop.
Perhaps characterizing BSD as being like a HAZMAT suit to me is a little harsh. It's more like I consider my firewall that way, regardless of the OS -- harsh, hard, and foreboding.
Anyway, I grew up mostly SysV. Is it surprising that BSD tastes funny to me?
this sounds more to me like give someone a hammer everything looks like a nail. You are useing linux because you are more comfortable useing it not because it is the best tool for the job.
You didn't read what I wrote really closely, did you? For my desktop machine, what matters most is that I find my computing experience comfortable and reasonable and get what I need to do done. I do that best in Linux. For my firewall box, I need something that's reliable, solid, secure, and stable. The consensus among a large number
of people is that OpenBSD has a noticeable (and some would say significant) edge over Linux here. (Particularly if you install an overloaded Linux distribution which ships far too many holes.)
How is that not the right tool for the task?
It's sorta like saying, "I'm more comfortable in jeans, T-shirt and sneakers, so that's what I wear everyday. But when I'm out cleaning Superfund sites, I wear a HAZMAT suit." For everyday situations, comfort is more important. For hostile environments, having hardened, impervious gear is more important than comfort.
Ever used a kernel without userspace? Yes. MS-DOS, I believe it was called.
I think you have it backwards. MS-DOS was more like a userspace without a kernel. That's why each program of any substance ended up coming packaged with its own protected-mode extender...
Anyway, to drift ever so slightly back on topic,
I too am somewhat interested in trying *BSD again. The last time I tried it, I had a working
Linux box, and the FreeBSD driver didn't like my EISA SCSI card. (I've gotten a better machine since then for my desktop box, but that old beater still exists as my firewall.)
Most likely, though, I'll just end up going with OpenBSD on my firewall box and running Linux on my desktop machine. I'm more comfortable in Linux than BSD, and so I think I'll just use "the right tool for the task."
I guess the main thing is that I prefer the
particular blend of BSD vs. SysV that Linux has,
as compared to the solid BSD flavor of the *-BSD
variants and the (mostly) solid SysV flavor of
OSes like Solaris. I cut my UNIX teeth on an
AT&T SVR4 box, but I also got a SunOS 4.x
account shortly thereafter. So, early on, I got
a taste of what worked best in both worlds.
Linux, with its ecclectic "We take what works for
us" approach seems to match my desires most closely. (And since I use Solaris daily at work, I'm probably leaning further away from BSD over time.)
So in the end, the machines I need to interact with regularly will probably be Linux boxes, and the machines I need to set up and forget about (and have just working) may end up being
*BSD boxes. (Of course, my firewall box happens to be the one with the unhappy EISA card, so until
it gets upgraded...)
BTW, did anyone else notice that the article
called the interface a noun-verb interface
rather than a verb-noun interface? Is it just me, but does DISPLAY VELOCITY sound more verb-nounish than vice-versa?
Uhm, news for you: PCI is much more than 2x as fast as ISA. ISA is 16-bits wide and 8.33MHz.
PCI is at least 33MHz and 32-bits wide. That's
rougly 8x faster. And then there's the 64-bit variant, etc...
This game has the interesting property there is no way to win it. The
logical stragity will cause you to get a horrible score, if your opponent is as logical as you.
Ok, I can definitely see that if you have two isolated tasks, each of which would fit in the cache on its own, but both of which would thrash each other in a single-CPU environment, you could get a superlinear speedup by going to multiple CPUs.
Uhm, each CPU still has the same amount of CPU cache, and if you've poorly divided the workload, you'll actually slow down processing due to cache-to-cache transactions. (These actually
get worse as caches get bigger.)
Basically, CPU A doesn't benefit from CPU B's cache (it might actually take a slight hit),
and vice versa.
The 2x increase in total CPU cache partitioned
across the CPUs just about guarantees a linear speedup for most things as a result.
I don't follow where you determined that this was I/O bound. If a machine was truly I/O bound it would scale sub-linearly with respect to available CPU cycles. And besides, most of the stuff should be in the disk cache anyway after the first parsing.
The re-parsing isn't terribly expensive, though it would be more expensive than parsing a binary representation of the same data. If the data is already in the cache, though, the cost is small relative to the rest of the work of compilation,
I'd imagine.
To convince myself of this, I ran a quick test with a smaller test case -- source code to an emulator I'm writing. If I compile the code with
"gcc -O6 -fomit-frame-pointer", it takes 37.65 seconds to compile. If I compile with no optimization flags at all, it takes 22.96 seconds to compile. This implies that the -O6 -fomit-frame-pointer optimizations cost about 15 seconds out of a 38 second compile! That's pretty significant.
Additionally, when I timed it, it said it got 98% CPU -- that too implies that I didn't spend much time in disk-wait.
(Note, I did a "make ; make clean" before running this test so that all of the source files were cached already to give a level playing field.)
Now what I will agree with is that single-threaded computation is slowed down because computation and I/O aren't overlapped. But that's quite different than being I/O bound.
Hmm... could be a RAM issue, or a front-side bus issue. I know my fiancee's dual 450MHz Pentium II box (which has a 100MHz FSB) is about 3x faster at building the kernel (just shy of 3x) than my single 300MHz Pentium II (with 66MHz FSB).
Between MHz and SMP, she got nearly 100% of the
extra CPU's benefit, and this is with a 2.2.x
kernel.
(It's my turn for a CPU upgrade next. Dual 1.2GHz Athlon with DDR is my current dream machine.)
Ah yes... I remember the days of Turbo C's precompiled header files.:-)
Not a bad idea, actually, but really a lot of
the compilation time in the compiler is now spent in the optimization stages, not the parsing stages. (Particularly in the compiler I use at
work.)
No, it was a bogus test. The author did "make bzImage" for the uniprocessor test and "make -j3 bzImage" on the multiprocessor test. If he'd done "make -j3 bzImage" for both, he would've discovered that the machine sped up by less than 100% most likely.
The thing is, "make -jX" for about
1 < X <= 4 still gives a speedup on uniprocessor systems because some compile tasks can be in disk-wait while others sit on the CPU.
(The optimal number for X depends on how fast your disks are and how much RAM you have. If X is too big, you start swapping, and end up losing performance.)
Whatever, troll. Interpreted languages are
only even marginally viable since the interpreters are themselves compiled. What happens when you only have interpreters? You'd need a 4GHz machine just to be where you were at yesterday with a 40MHz machine.
Well, how about a hard, real-world example.
Granted, this is a "toy" by many standards, but
it was definitely a case where I applied the 50-50 rule. On the plus side, we do value documentation in our shop.
Some of the code I was inheriting contained this
gem:
short *arr_ptr[8];
/*... snipped... */
for( j
= 0; j < 8; j++) {
arr_ptr[j] = (short *) malloc(1 * sizeof(short *)); if
(!arr_ptr[j]) printf("\n Unable to allocate space for
ln_buffer\n"); if (!arr_ptr[j]) exit(2);
}
for ( i = 0; i < ish_y_dim; i+=2) {
iptr += 2*ish_x_dim; if (iptr > xend) iptr = xstart;
Now tell me, why's that malloc() there and where's the memory going? That entire first loop has no reason to exist! As it was, the rest of the code was also overly complex and none of it was doing what it really should be doing. The stuff it was doing it was doing in a rather tortured way.
So, I threw out that function entirely and wrote a much cleaner new one. Right now, I've got some other code I've inherited that's a bit larger than this, and I really, really want to rewrite it. Fortunately, though, I'm not being asked to maintain it -- just run it. Since I don't have the time to rewrite it, and I'm not charged with maintaining it, I think I'll just let sleeping dogs lie.
You can understand its function without understanding its implementation.
For instance, if you program C, you know
pretty well how "printf()" is
supposed to work. If you then go open the
hood on the printf implementation with intention
of adding something to it (say, a new % operator) and discover it to be the biggest pile of rotten
bits you've ever seen, then the 50/50 rule
applies.
Often, it's much easier to figure out what the
interface to a black box is than it is to understand the contents of the box when you open it.
Related subthread... If you're using a new enough Sparc CPU (chances are very good you are if you're machine is at all faster than a 486), adding the -mv8 switch to GCC is also sometimes good for as much as 10% performance gain depending on your instruction mix. In my code it was a nice win. From the GCC
manpage:
-mv8 will give you SPARC v8 code. The only difference
from v7 code is that the compiler emits the integer
multiply and integer divide instructions which exist in
SPARC v8 but not in SPARC v7.
There may be additional such flags in newer GCCs. (I'm still using 2.8.1 at work.)
In my day job, I'm occasionally charged with the task of writing code that takes our processor architecture to the limit. We're talking every cycle count, codesize is important, and functionality must not be overly compromised. I've been fairly proud of most of my results, and I think they're quite beautiful examples of what can happen when you first design a well-thought-out piece of functionality, and then optimize it to the hilt.
In my application space, this is appropriate. I'm coding for a DSP, and the functions I'm coding are individual DSP processing steps. These are nice, separable functions that some would have us implement directly in silicon. My job is to show them that a programmable processor can do the job.
The following links show some of these "DSP kernels" that I am especially fond of.
In my opinion, this code is actually fairly well structured for assembly code. All of the hardware registers have been abstracted behind.asg directives, so that they can be given human-readable names. These names relate back to the C code description of the function (which is also provided in a comment block attached to the code). As an added bonus, comments throughout the code explain the numerous optimizations.
In a different realm, I have a mix of beautiful and ugly code for an entirely different platform.
Recently, I've written a Falling Tetrominoes Game for Intellivision named 4-Tris. The assembly code for this
game is rather clean and heavily documented. The game actually implements a lightweight task scheduler and then builds the game on top of that as a series of event handlers.
Of course, there are some definitely UNbeautiful bits around the edges. There's a
Pong game hidden in there that's written as nearly complete line-noise. Also, the
song format compiler is an absolute hackish mess.
So, it's safe to say that my code runs the gamut from clean and clear to nearly line-noise.
BTW, for those who are interested, I also have
a Monitor Program that I wrote for the 8051/8052 microcontroller. I can't decide if it's ugly or beautiful. The problem here is that the architecture itself is downright ugly, but some of the optimization tricks in the code are either beautiful, insane, or par for the 8051 course.:-) At the very least, I consider it ugly compared to 4-Tris and the DCTs above, so...
--Joe --
Re:Filesystem inaccuracy
on
2.2 vs 2.4
·
· Score: 1
Indeed, the FAQ for the HFS filesystem driver in the Linux 2.2 source tree states:
8. Will it run on my (your processor type here)? The code is carefully written to be independent of your processor's
word size and byte-order, so if your machine runs Linux it can run the
HFS filesystem. However some younger ports don't yet have support for
loadable modules.
Note that HFS is tested most extensively on Intel platforms. So there
could be subtle compilation problems on other platforms. If you
encounter any that are not addressed by the documentation then please
let me know.
So, it would seem that actually it should work
on x86 first.
Average US household has the TV on for ~7hrs a day, even though it's only watched for about half that time. Most (near 100%) of households have TVs, and most of those TVs are larger (and draw more power) than typical computer monitors.
In contrast, fewer people have computers, and fewer still leave them on 24/7. (Just because people here on Slashdot leave their PCs on 24/7 doesn't mean the rest of the world (or even the bulk of California) is.) Most people also use the Windows default settings for APM which do shave a few Watts. (Ever hear of Energy Star?) Same goes for those PCs at work.
Transmeta is under no obligation to build the next Crusoe with the same ISA,
and probably won't.
...and already haven't. Their existing two part
families (the TM3200 and TM5400/TM5600) have different ISAs under the hood. Apparently, the TM3200 doesn't handle legacy 16-bit code as well,
so they went back and improved that with extra functionality found only in the TM5xxx families.
Now what would be interesting is if Transmeta offered a better "meta-assembly language" that was both easier for them to decode and translate, and simultaneously served as a better compiler target. That's perhaps asking too much.
At least the
"Transmeta running x86-64/AMD-Hammer"
thing sounds interesting...
On a different note, another reason they don't want you coding to the native ISA is that not only are the x86 instructions emulated, but also some of the legacy x86 peripherals are emulated as well. It makes perfect sense to at least partially swallow up some things, like timers and interrupt controllers and emulate them in software, avoiding unneeded bus traffic. It speeds up the CPU and reduces power.
Slashdot Mirror
I'm using a Linux 486 box presently myself. I want / need more services on that box though. Load isn't an issue at all. Security holes are the main gripe. Typically, I like to run telnet (grr... I'm stuck with a couple places I can only telnet from, not ssh from), httpd, and squid, among other things. (At least telnetd is wrapped with a TCP wrapper so only a couple hosts can connect.) I also would like to run (but am rightfully afraid to) FTPD as it makes sharing files much easier. (I have some friends whose http proxy won't let them download files with certain extensions -- eg. mp3 -- but they can FTP just fine.) Every time I see a RH Linux advisory, I cringe.
Right now, I feel I'm reasonably secure as long as I don't enable sendmail, and keep FTPD turned off. Apache will be the same regardless of OS. SSHD doesn't change really, either. So, the OS doesn't matter too much. But still, with that many services running, it's tempting to use an OS whose goal is to be stable, correct, and by extension, secure. Linux simply lacks that maniacal focus.
FWIW, that machine still has Linux on it though. That whole inertia thing. :-)
--Joe--
BSD users find BSD comfortable. What a news flash! Every day, I interact with a Solaris machine (at work), a Linux machine (at home), and a BSDi (at my ISP). As long as I set my shell to bash and have the GNU utils override the defaults where possible, I don't notice much of a difference between the three. There's the occasional nit, though, and I have fewer of them on Linux. Also, I don't need to install GNU utils to override the defaults there. So, for me (and it really is me that matters most when picking an OS for my desktop box), Linux is the right choice. For my friend down the hall from me, FreeBSD was the right choice for him for his desktop.
Perhaps characterizing BSD as being like a HAZMAT suit to me is a little harsh. It's more like I consider my firewall that way, regardless of the OS -- harsh, hard, and foreboding.
Anyway, I grew up mostly SysV. Is it surprising that BSD tastes funny to me?
--Joe--
You didn't read what I wrote really closely, did you? For my desktop machine, what matters most is that I find my computing experience comfortable and reasonable and get what I need to do done. I do that best in Linux. For my firewall box, I need something that's reliable, solid, secure, and stable. The consensus among a large number of people is that OpenBSD has a noticeable (and some would say significant) edge over Linux here. (Particularly if you install an overloaded Linux distribution which ships far too many holes.)
How is that not the right tool for the task?
It's sorta like saying, "I'm more comfortable in jeans, T-shirt and sneakers, so that's what I wear everyday. But when I'm out cleaning Superfund sites, I wear a HAZMAT suit." For everyday situations, comfort is more important. For hostile environments, having hardened, impervious gear is more important than comfort.
--Joe--
I think you have it backwards. MS-DOS was more like a userspace without a kernel. That's why each program of any substance ended up coming packaged with its own protected-mode extender...
Anyway, to drift ever so slightly back on topic, I too am somewhat interested in trying *BSD again. The last time I tried it, I had a working Linux box, and the FreeBSD driver didn't like my EISA SCSI card. (I've gotten a better machine since then for my desktop box, but that old beater still exists as my firewall.)
Most likely, though, I'll just end up going with OpenBSD on my firewall box and running Linux on my desktop machine. I'm more comfortable in Linux than BSD, and so I think I'll just use "the right tool for the task."
I guess the main thing is that I prefer the particular blend of BSD vs. SysV that Linux has, as compared to the solid BSD flavor of the *-BSD variants and the (mostly) solid SysV flavor of OSes like Solaris. I cut my UNIX teeth on an AT&T SVR4 box, but I also got a SunOS 4.x account shortly thereafter. So, early on, I got a taste of what worked best in both worlds. Linux, with its ecclectic "We take what works for us" approach seems to match my desires most closely. (And since I use Solaris daily at work, I'm probably leaning further away from BSD over time.)
So in the end, the machines I need to interact with regularly will probably be Linux boxes, and the machines I need to set up and forget about (and have just working) may end up being *BSD boxes. (Of course, my firewall box happens to be the one with the unhappy EISA card, so until it gets upgraded...)
--Joe--
BTW, did anyone else notice that the article called the interface a noun-verb interface rather than a verb-noun interface? Is it just me, but does DISPLAY VELOCITY sound more verb-nounish than vice-versa?
:-)
--Joe--
Uhm, news for you: PCI is much more than 2x as fast as ISA. ISA is 16-bits wide and 8.33MHz. PCI is at least 33MHz and 32-bits wide. That's rougly 8x faster. And then there's the 64-bit variant, etc...
--Joe--
Forget make clean did we?
--
Sorta reminds me of that quote from War Games:
--Joe--
Ok, I can definitely see that if you have two isolated tasks, each of which would fit in the cache on its own, but both of which would thrash each other in a single-CPU environment, you could get a superlinear speedup by going to multiple CPUs.
--Joe--
Uhm, each CPU still has the same amount of CPU cache, and if you've poorly divided the workload, you'll actually slow down processing due to cache-to-cache transactions. (These actually get worse as caches get bigger.)
Basically, CPU A doesn't benefit from CPU B's cache (it might actually take a slight hit), and vice versa. The 2x increase in total CPU cache partitioned across the CPUs just about guarantees a linear speedup for most things as a result.
--Joe--
I don't follow where you determined that this was I/O bound. If a machine was truly I/O bound it would scale sub-linearly with respect to available CPU cycles. And besides, most of the stuff should be in the disk cache anyway after the first parsing.
The re-parsing isn't terribly expensive, though it would be more expensive than parsing a binary representation of the same data. If the data is already in the cache, though, the cost is small relative to the rest of the work of compilation, I'd imagine.
To convince myself of this, I ran a quick test with a smaller test case -- source code to an emulator I'm writing. If I compile the code with "gcc -O6 -fomit-frame-pointer", it takes 37.65 seconds to compile. If I compile with no optimization flags at all, it takes 22.96 seconds to compile. This implies that the -O6 -fomit-frame-pointer optimizations cost about 15 seconds out of a 38 second compile! That's pretty significant.
Additionally, when I timed it, it said it got 98% CPU -- that too implies that I didn't spend much time in disk-wait.
(Note, I did a "make ; make clean" before running this test so that all of the source files were cached already to give a level playing field.)
Now what I will agree with is that single-threaded computation is slowed down because computation and I/O aren't overlapped. But that's quite different than being I/O bound.
--Joe --Joe--
Hmm... could be a RAM issue, or a front-side bus issue. I know my fiancee's dual 450MHz Pentium II box (which has a 100MHz FSB) is about 3x faster at building the kernel (just shy of 3x) than my single 300MHz Pentium II (with 66MHz FSB). Between MHz and SMP, she got nearly 100% of the extra CPU's benefit, and this is with a 2.2.x kernel.
(It's my turn for a CPU upgrade next. Dual 1.2GHz Athlon with DDR is my current dream machine.)
--Joe--
Ah yes... I remember the days of Turbo C's precompiled header files. :-)
Not a bad idea, actually, but really a lot of
the compilation time in the compiler is now spent in the optimization stages, not the parsing stages. (Particularly in the compiler I use at
work.)
--Joe--
No, it was a bogus test. The author did "make bzImage" for the uniprocessor test and "make -j3 bzImage" on the multiprocessor test. If he'd done "make -j3 bzImage" for both, he would've discovered that the machine sped up by less than 100% most likely.
The thing is, "make -jX " for about 1 < X <= 4 still gives a speedup on uniprocessor systems because some compile tasks can be in disk-wait while others sit on the CPU. (The optimal number for X depends on how fast your disks are and how much RAM you have. If X is too big, you start swapping, and end up losing performance.)
--Joe--
Whatever, troll. Interpreted languages are only even marginally viable since the interpreters are themselves compiled. What happens when you only have interpreters? You'd need a 4GHz machine just to be where you were at yesterday with a 40MHz machine.
--Joe--
Steve Jobs is Linus Torvalds? Nah... don't think so. :-)
--Joe--
Your sig is a step in the right direction...
--Joe--
Well, how about a hard, real-world example. Granted, this is a "toy" by many standards, but it was definitely a case where I applied the 50-50 rule. On the plus side, we do value documentation in our shop.
Some of the code I was inheriting contained this gem:
short *arr_ptr[8];
for( j = 0; j < 8; j++)
{
arr_ptr[j] = (short *) malloc(1 * sizeof(short *));
if (!arr_ptr[j]) printf("\n Unable to allocate space for ln_buffer\n");
if (!arr_ptr[j]) exit(2);
}
for ( i = 0; i < ish_y_dim; i+=2)
{
iptr += 2*ish_x_dim;
if (iptr > xend) iptr = xstart;
ptr = iptr;
for( j = 0; j < 8; j++)
{
arr_ptr[j] = ptr;
ptr += ish_x_dim;
if (ptr > xend) ptr =ish_image;
}
}
Now tell me, why's that malloc() there and where's the memory going? That entire first loop has no reason to exist! As it was, the rest of the code was also overly complex and none of it was doing what it really should be doing. The stuff it was doing it was doing in a rather tortured way.
So, I threw out that function entirely and wrote a much cleaner new one. Right now, I've got some other code I've inherited that's a bit larger than this, and I really, really want to rewrite it. Fortunately, though, I'm not being asked to maintain it -- just run it. Since I don't have the time to rewrite it, and I'm not charged with maintaining it, I think I'll just let sleeping dogs lie.
--Joe--
It'd probably use something like this for its logo.
(Interestingly, I have that exact picture in my office...)
--Joe--
You can understand its function without understanding its implementation. For instance, if you program C, you know pretty well how "printf()" is supposed to work. If you then go open the hood on the printf implementation with intention of adding something to it (say, a new % operator) and discover it to be the biggest pile of rotten bits you've ever seen, then the 50/50 rule applies.
Often, it's much easier to figure out what the interface to a black box is than it is to understand the contents of the box when you open it.
--Joe--
Related subthread... If you're using a new enough Sparc CPU (chances are very good you are if you're machine is at all faster than a 486), adding the -mv8 switch to GCC is also sometimes good for as much as 10% performance gain depending on your instruction mix. In my code it was a nice win. From the GCC manpage:
There may be additional such flags in newer GCCs. (I'm still using 2.8.1 at work.)
--Joe--
In my day job, I'm occasionally charged with the task of writing code that takes our processor architecture to the limit. We're talking every cycle count, codesize is important, and functionality must not be overly compromised. I've been fairly proud of most of my results, and I think they're quite beautiful examples of what can happen when you first design a well-thought-out piece of functionality, and then optimize it to the hilt.
In my application space, this is appropriate. I'm coding for a DSP, and the functions I'm coding are individual DSP processing steps. These are nice, separable functions that some would have us implement directly in silicon. My job is to show them that a programmable processor can do the job.
The following links show some of these "DSP kernels" that I am especially fond of. In my opinion, this code is actually fairly well structured for assembly code. All of the hardware registers have been abstracted behind .asg directives, so that they can be given human-readable names. These names relate back to the C code description of the function (which is also provided in a comment block attached to the code). As an added bonus, comments throughout the code explain the numerous optimizations.
In a different realm, I have a mix of beautiful and ugly code for an entirely different platform. Recently, I've written a Falling Tetrominoes Game for Intellivision named 4-Tris. The assembly code for this game is rather clean and heavily documented. The game actually implements a lightweight task scheduler and then builds the game on top of that as a series of event handlers. Of course, there are some definitely UNbeautiful bits around the edges. There's a Pong game hidden in there that's written as nearly complete line-noise. Also, the song format compiler is an absolute hackish mess.
So, it's safe to say that my code runs the gamut from clean and clear to nearly line-noise.
BTW, for those who are interested, I also have a Monitor Program that I wrote for the 8051/8052 microcontroller. I can't decide if it's ugly or beautiful. The problem here is that the architecture itself is downright ugly, but some of the optimization tricks in the code are either beautiful, insane, or par for the 8051 course. :-) At the very least, I consider it ugly compared to 4-Tris and the DCTs above, so...
--Joe--
Indeed, the FAQ for the HFS filesystem driver in the Linux 2.2 source tree states:
So, it would seem that actually it should work on x86 first.
--Joe--
Average US household has the TV on for ~7hrs a day, even though it's only watched for about half that time. Most (near 100%) of households have TVs, and most of those TVs are larger (and draw more power) than typical computer monitors.
In contrast, fewer people have computers, and fewer still leave them on 24/7. (Just because people here on Slashdot leave their PCs on 24/7 doesn't mean the rest of the world (or even the bulk of California) is.) Most people also use the Windows default settings for APM which do shave a few Watts. (Ever hear of Energy Star?) Same goes for those PCs at work.
--Joe--
Now what would be interesting is if Transmeta offered a better "meta-assembly language" that was both easier for them to decode and translate, and simultaneously served as a better compiler target. That's perhaps asking too much. At least the "Transmeta running x86-64/AMD-Hammer" thing sounds interesting...
On a different note, another reason they don't want you coding to the native ISA is that not only are the x86 instructions emulated, but also some of the legacy x86 peripherals are emulated as well. It makes perfect sense to at least partially swallow up some things, like timers and interrupt controllers and emulate them in software, avoiding unneeded bus traffic. It speeds up the CPU and reduces power.
--Joe--