21 Apr
2002
21 Apr
'02
10:27 p.m.
It was thus said that the Great ajp166 once stated:
No, I am aware of other CPU manufacturers than Intel. I've used computers
based upon the Motorola 68k (Amiga with a 68000, a Tandy-6000 with a 68000,
the Sun-3 series based upon 68020s or higher, some HPs), MIPS (SGI
machines), Sparc (Sun-4 series on up), PA-RISC (some other HPs), PowerPC
(IBM machines) and the ubiquitous x86 series (Linux, FreeBSD, OpenBSD,
MS-DOS, Windows, OS/2). All systems I've developed for (used, however, is a
slightly longer list).
As for using non-8 bit byte based CPUs? Not really; I don't think I've
ever even come across any 9, 12, 18, 24, 36, 60 or 66 bit systems
*anywhere* and I'm one of the few programmers I know that's even *heard* of
such CPUs. Most programmers I suspect are only aware of the x86.
And yes, there is a difference between ``portable'' and ``ported to.''
I
try to write what is ``portable'' code.
I was talking about my code. Yes, I've had experience where the porting
was painful (two weeks to ``port'' a Unix editor to QNX---God I wanted to
shoot the developer of that program, and another program I had to rewrite
for scratch because the original developer didn't care about programming at
all, and didn't want to support his mess).
I'm aware of that. I started coding in C in 1990, *after* the ANSI-C
standard was ratified so that did help (and it probably doesn't help much
that I refuse to work with anything written in K&R C)).
-spc (Have compiler, will program)
[1] Footnote not found. Check original message.
[2] Footnote not found. (A)bort, (R)etry, (F)ail?
That doesn't make sense. UNIX you state as
being easily ported, even
though as a kernel it has to hit the hardware pretty hard, yet you state
applications as not being portable at all, because of the underlying
hardware and processor (which the application shouldn't care about). If
anything, I would think the opposite would be true.
You forget I guess. All cpus are from intel. At one time unix was on
machines of different word size and instruction set. So an app while easily
ported to a new platform, it was not without some problems. Like each
version of unix was not always the same as another. Some of those were
those little things like the apps programmer needed a target machine and OS
to verify on. So "portable" is not the same as "ported to". I didn't say it wasn't possible only that
saying the OS is unix meant it was
not always a slam dunk and that compliation was often required.
Um ... I thought compilation was *always* required (unless you are using
USCD Pascal, Java or C#).
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.
Thanks for the tutorial, I heard it back it 82 also. Experence however
proved otherwise in practical terms. [2] Okay, one
problem---the DEC Alpha port crashed, but it was tracked
down to a bug in the C library call memchr().
In the past 1983-1988 that was far more commonplace to have incompatable
compilers libraries.