21 Apr
2002
21 Apr
'02
4:56 p.m.
From: Sean 'Captain Napalm' Conner <spc(a)conman.org>
> 8080/z80 and if it was DOS you could bet on 808x.
Unix back then
meant
> MIPS, VAX, PDP-11, SUN/sparc, 68000, Z8000, and a
few dozen I likely
missed.
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".
Now, speaking as a programmer who's done cross
platform programs, I've
come to the conclusion that writing portable software isn't difficult
and
with enough experience it becomes quite easy in fact.
It's programmers
that
make unwarrented assumptions about their code or
platform that make for
unportable applications.
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.
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.
Allison
21 Apr
21 Apr
6: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. 
6:53 p.m.
Sean 'Captain Napalm' Conner wrote:
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.
What computer
systems did you have in mind?
9 bit ????
12 bit ????
...
--
Ben Franchuk - Dawn * 12/24 bit cpu *
www.jetnet.ab.ca/users/bfranchuk/index.html
7:27 p.m.
It was thus said that the Great Ben Franchuk once stated:
Sean 'Captain Napalm' Conner wrote:
I might have gotten a bit confused there. I know of systems that have had
9 bit characters, and some that have 12 bit address spaces but I'm sure that
if there were indeed, such things as a nine bit or twelve bit computer,
they'll be mentioned soon enough 8-/
-spc (But I do want to say the PDP-8 was a 12 bit system for some reason ... )
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.
What computer
systems did you have in mind?
9 bit ????
12 bit ????
8154
days inactive
8154
days old
3 comments
3 participants
participants (3)
-
ajp166＠bellatlantic.net -
bfranchuk＠jetnet.ab.ca -
spc＠conman.org