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

From: Richard Erlacher <edick_at_idcomm.com>
Date: Mon Apr 22 00:35:53 2002

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_at_conman.org>
To: <classiccmp_at_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.
>
>
>
Received on Mon Apr 22 2002 - 00:35:53 BST