Micro$oft Biz'droid Lusers (was: OT email response format)

From: Sean 'Captain Napalm' Conner <spc_at_conman.org>
Date: Sun Apr 21 22:06:46 2002

It was thus said that the Great Richard Erlacher once stated:
>
> > Granted, on the 8-bit systems you often times had to code in Assembly,
> > both for speed and size reasons (and because compilers for such systems
> > weren't good enough) but when you get to UNIX the whole point was to avoid
> > assembly in the first place [1]. Therefore, you are writing in a higher
> > level, more portable language and then it becomes possible to write code
> > that will run across platforms. Heck, I've written a program that has
> > compiled across several different UNIX platforms (SGI, Linux on the x86,
> > Linux on the DEC Alpha, OpenBSD, FreeBSD) without problems [2] and you'll
> > notice that there is at least one 64-bit architecture listed there. The
> > same code was successfully compiled (with one line of code change, plus a
> > few other lines to get the correct header files loaded) under Microsoft
> > Windows. Okay, it may not have been optimum code under Windows, but it
> > still ran with minimum of changes or fuss.
>
> This is true if you've got a set of software tools that really exploits the
> hardware effectively. Few do that. The result may be that you have a bit of
> software that works well on one platform but not so well on the others, and
> perhaps very badly on one or two.

  I've used software specifically coded straight to the hardware of the
Amiga, and it still failed to work on *my* Amiga, due to differences in
timing between the European and American versions of the hardware (and that
being the *only* differences). You may consider it as two different
platforms, but I don't. And there were ways to write code that would work
(while hitting the hardware) on any Amiga, reguardless of geographic
location. Okay, so you loose a few cycles checking a status bit in hardware
to see if something has finished (as opposed to *knowing* that it takes X
cycles to do, and therefore since the machine runs at Y Mhz you have time
for Z instructions).

  As far as the software I've written, it doesn't pay for me to code it in
Assembly, even though I know it for several architectures, as my code could
possibly run on different platforms (even the same architecture under
different operating systems). Heck, the same program I mentioned above was
a rewrite of a previous version with a slightly different internal
architecture to support more features. The rewrite ran slower than the
original (but both were in C).

  Instead of worrying about the speed problem, I kept coding until the
program worked. Then profiled the code to see where the hot spots where and
with just seven changes to the code (mainly, making what where functions
into macros that expanded inline) was able to increase the speed to match
the previous version, with more functionality (oh, and I kept the functions
around to aid with testing---it's sometimes easier to test C code as
functions than as macros).

  And if it was still too slow, *then* I drop down into assembly for the
platform dujour.

  It's not rocket science.

> > [2] Okay, one problem---the DEC Alpha port crashed, but it was tracked
> > down to a bug in the C library call memchr().
>
> My neighbor just scrapped two brand-new Alpha stations because they wouldn't
> run the 64-bit UNIX version the vendor, now history, produced them for. He
> couldn't, after several months of effort even get any one to buy the boxes for
> the box/PSU combo. He put them in the dumpster, still in their plastic wrap.
> I wish he'd offered me the enclosures with the PSU's ...

  Let me guess, Ultrix? I've seen Linux run without problem on DEC Alphas
(heck, I have a friend that runs several DEC Alpha with Linux without
problem). And the bug I mentioned above was only found because I apparently
was the *only* person so far to call the function with the parameters I did
(with values that are legal values for ANSI-C (of which the compiler and
library conformed to) but are almost never used). As it was, I could code
around it for the DEC Alpha and submit a bug report to the GNU C-library
maintainers [1].

  -spc (Who still does development on a 120MHz AMD 486 clone ... )

[1] Which is how I think I got invited to the RedHat IPO. Never has a
        bug report been so profitable 8-) Surprised me to no end.
Received on Sun Apr 21 2002 - 22:06:46 BST