Since the former thread title was <OT email response format> I'd point out
that the only part of this quoted text that I originated is the part beginning
with "This is true if you've got ..." though I'm getting credit for
wisdom for
which I can't take credit. Not being a software weenie, I'd never have made
the claim in the topmost quoted section.
The "True 64-bit UNIX" for which my neighbor bought his now-discarded Alpha
boxes is unfamiliar to me, but wasn't ULTRIX, since I'd heard that name
before. This was an Alpha-specific product, the vendor of which apparently
has gone under or something ...
Dick
----- Original Message -----
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org>
To: <classiccmp(a)classiccmp.org>
Sent: Sunday, April 21, 2002 9:06 PM
Subject: Re: Micro$oft Biz'droid Lusers (was: OT email response format)
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.