21 Apr
2002
21 Apr
'02
12:59 p.m.
To: classiccmp(a)classiccmp.org <classiccmp(a)classiccmp.org>
Date: Sunday, April 21, 2002 1:28 PM
The whole mid 80s thing with workstations was a disaster in many respects
as everyone was trying to put more processor in a box and unix was the OS
of
choice as it was easily ported and offered most of the higher level OS
functions
that stuff like DOS was clueless about. The problem was unix was easily
ported
though it didn't make for portable apps, usually due to underlying
hardware or
even the basic processor. In that respect CP/M and DOS made it easier as
at least if it was CP/M-80 you knew your base cpu was 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.
I've got about half-a-dozen of the free
assembler/simulator/debugger
packages
for Windows some of which come along with compilers for
PL/M, Pascal,
and 'C.'
I'm certainly not surprised that there are UNIX
tools of that sort
around,
since the 805x core has been around since '84 or
so, when I started with
it.
Back then, BTW, there was no Windows, nor was there
much freeware. I
used
UNIX on SUN hardware back then and it cost $100K a year
for the
personnel
needed to keep the rather small SUN system running.
The typical EDA
software
package cost over $200K and was patched about once a
month, resulting in
about
ten days' downtime per patch.
Note the 8051 is 1981.
I started with that chip using freeware under CP/M-80 and still use most
of those
tools. When there was a requirement I'd use a commercial compiler from
Avocet
systems a relatively inexpesive package back then. The idea that PCs
were a
unversal platform and was foreign to me until the vary late 80s ('89!).
Even then
DOS was the default not winders, assuming it wasn't SCO unix or the like.
In the end a lot has been forgotten about the timeframe from 82 to about
88
where there was not just a little flux in the market and the PC was only
one
player.
happily went back to CP/M, which served much better, in
my view.
Unfortunately, there was little freeware of any use for CP/M just as
there is
for Windows. The OS was not available in source form,
nor was it likely
you'd
Actually there was but the problem of incompatable media was crippling
unless
you had the majik 8"sssd box. The realy 80s was an explosive time for
CP/M-80 software if you could get it in a form you could use. There was
a
large amount stuff published, but typing in 8-10 pages of listing was
often
a good reason not to persue it. What was also a bonus was the amount of
cheapware (low cost), stuff that was good but, cheap to buy.
find source code for any application that was of any
use. Back then, if
you
wanted development software tools that worked pretty
well, you bought
Microsoft compilers, assemblers, linkers, etc. Their stuff worked, was
adequately documented, etc.
Actually back (pre 83ish) then MS was a language and development tool
house
and I'd say a fairly decent one at the time.
Nothing lasts forever, though.
Roger that!
Allison
21 Apr
21 Apr
1:24 p.m.
ajp166 wrote:
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.
Back then too having more than 64kb of memory was real feat. Looking
back in hindsite most the unix tools I think from that era were 64k code
and 64k data. Something 16 bit computers could handle but not much more.
Remember 8086 segment registers.?? The lack of free open source C
compiler was problem too.
Ben Franchuk - Dawn * 12/24 bit cpu *
www.jetnet.ab.ca/users/bfranchuk/index.html
2:20 p.m.
----- Original Message -----
From: "ajp166" <ajp166(a)bellatlantic.net>
To: <classiccmp(a)classiccmp.org>
Sent: Sunday, April 21, 2002 11:59 AM
Subject: Re: Micro$oft Biz'droid Lusers (was: OT email response format)
Since the only standard format for CP/M was the SSSD (IBM 3740)
diskette, I believed then, as I still do, that your computer wasn't a
CP/M box unless it had those drives on it. I'm looking to rework a
design for the early Ampro Little Board, but with a 1797 instead of the
1770 just to get that. Of course there are still a zillion other formats
that it won't deal with properly for a while ...
To: classiccmp(a)classiccmp.org
<classiccmp(a)classiccmp.org>
Date: Sunday, April 21, 2002 1:28 PM
The whole mid 80s thing with workstations was a disaster in many respects
<snip>
Unfortunately,
there was little freeware of any use for CP/M just as
there is
for Windows. The OS was not available in source
form, nor was it likely
you'd
Actually there was but the problem of incompatable media was crippling
unless
you had the majik 8"sssd box. The realy 80s was an explosive time for
CP/M-80 software if you could get it in a form you could use. There was
a large amount stuff published, but typing in 8-10 pages of listing was
often
a good reason not to pursue it. What was also a bonus was the amount of
cheapware (low cost), stuff that was good but, cheap to buy.
There were plenty of development tools and "avant-garde" software for
dabblers, but little of any serious interest. It might have changed had it
not been for the arrival of the PC. <sigh>
Getting a complete picture of what was "out there" by way of freeware
and the like was terribly difficult at the time because there was no
generally accessible internet and there were no reasonably priced
home computers that were internet capable, even if there had been
an accessible 'net. Modems at 1200 baud were still costly, and that
was true, even for universities with their gazillions of taxpayer dollars.
> find source code for any application that was of any use. Back then, if
> you wanted development software tools that worked pretty well, you
> bought Microsoft compilers, assemblers, linkers, etc. Their stuff worked,
was
adequately
documented, etc.
Actually back (pre 83ish) then MS was a language and development
tool house and I'd say a fairly decent one at the time.
Nothing lasts forever, though.
Roger that!
Allison
5:32 p.m.
It was thus said that the Great ajp166 once stated:
The whole mid 80s thing with workstations was a disaster in many respects as
everyone was trying to put more processor in a box and unix was the OS of
choice as it was easily ported and offered most of the higher level OS
functions that stuff like DOS was clueless about. The problem was unix was
easily ported though it didn't make for portable apps, usually due to
underlying hardware or even the basic processor. In that respect CP/M and
DOS made it easier as at least if it was CP/M-80 you knew your base cpu was
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.
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.
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.
-spc (Whose first major program in C I ported (with real minimal changes)
between OS/2, MS-DOS, AmigaOS and UNIX ... )
[1] Unless speed was critical (remember, I'm talking about applications
under UNIX, which shouldn't hit the hardware at all), at which point
you find the bottle neck, and rewrite that portion in assembly, and
keep the original C around in case you have to port (or someone has
to port) the code to a new chip. The rest of the application can
remain in C.
[2] Okay, one problem---the DEC Alpha port crashed, but it was tracked
down to a bug in the C library call memchr().
7:32 p.m.
A lot depends on what you mean by "cross-platform-programming."
See below.
Dick
----- Original Message -----
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org To: <classiccmp(a)classiccmp.org Sent: Sunday, April 21, 2002 4:32 PM
Subject: Re: Micro$oft Biz'droid Lusers (was: OT email response format)
Some people believe cross-platform programming
means using the resources
common to all the platoforms. That produces portability at the expense of
efficiency. If you're willing to tolerate that, well, OK.
> 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.
> 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.
> 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.
> -spc (Whose first major program in C I
ported (with real minimal changes)
> between OS/2, MS-DOS, AmigaOS and UNIX ... )
> [1] Unless speed was critical (remember,
I'm talking about applications
> under UNIX, which shouldn't hit the hardware at all), at which point
> you find the bottle neck, and rewrite that portion in assembly, and
> keep the original C around in case you have to port (or someone has
> to port) the code to a new chip. The rest of the application can
> remain in C.
> [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 ...
It was thus said that the Great ajp166 once stated:
> The whole mid 80s thing with workstations
was a disaster in many respects
as
> everyone was trying to put more processor in a
box and unix was the OS of
> choice as it was easily ported and offered most of the higher level OS
> functions that stuff like DOS was clueless about. The problem was unix
was
> easily ported though it didn't make for
portable apps, usually due to
> underlying hardware or even the basic processor. In that respect CP/M and
> DOS made it easier as at least if it was CP/M-80 you knew your base cpu
was
> 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.
10:06 p.m.
It was thus said that the Great Richard Erlacher once stated:
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.
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.
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. [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 ...
22 Apr
22 Apr
12:35 a.m.
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)
wouldn't
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
> 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.
1:05 a.m.
It was thus said that the Great Richard Erlacher once stated:
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 top portion quoted was me, of which you responded to (starting with
``This is true if you've got ... '') and then my response to that. I still
don't know what you actually meant by your response, and my reply was an
attempt to answer what I thought you were trying to say by showing how
coding to the hardware, to get maximum performance, doesn't always work even
if the platform the program was written for doesn't change (significantly).
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 ...
The only operating systems that I'm aware of that were made for the DEC
Alpha were VMS (or is that OpenVMS), ULTRIX, Linux and maybe a certain
version of Windows NT. There might have been another UNIX variant made for
the DEC Alpha but I'm not aware of what it could be.
-spc (And I have to wonder what you actually use computers for ... )
1:24 a.m.
At 02:05 AM 22/04/2002 -0400, Sean 'Captain Napalm' Conner wrote:
The only operating systems that I'm aware of
that were made for the DEC
Alpha were VMS (or is that OpenVMS), ULTRIX, Linux and maybe a certain
version of Windows NT. There might have been another UNIX variant made for
the DEC Alpha but I'm not aware of what it could be.
Ultrix was never made available for the alpha. The Unix variant for alpha
was originally known as OSF/1 which became Digital Unix after most of the
OSF/1 consortium disappeared and then became Tru64 Unix after Compaq
purchased Digital.
Linux for alpha has some Compaq support engineers who help qualify Linux
for new Alpha systems.
Huw Davies | e-mail: Huw.Davies(a)kerberos.davies.net.au
| "If God had wanted soccer played in the
| air, the sky would be painted green"
1:43 a.m.
OK ... I said
:: 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.
and this was in the context of portable coding
so I meant that while you may have software that creates really pretty decent
code for one platform, that same source code may not produce as good a product
on another, and, in fact, may produce pretty bad code for yet another set of
hardware. There's plenty of evidence of that, at least according to people
with whom I routinely interact.
I personally code in assembler for the MCU's I use and occasionally use a
compiler if I have an environment where timing is not critical all the time
and where it's easier to use logic spelled out in 'C' or Pascal. That often
means that interrupt code is written in assembler while message generation or
communication code is produced by a compiler. Portability is seldom an issue
for me.
As for what I do with my computer(s), I use 'em as tools to earn a living,
which I've managed for quite a while now. I don't play games much, unless
I'm
waiting for some other task to finish.
Dick
----- Original Message -----
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, April 22, 2002 12:05 AM
Subject: Re: Micro$oft Biz'droid Lusers (was: OT email response format)
It was thus said that the Great Richard Erlacher once
stated:
>
> Since the former thread title was <OT email response format> I'd point out
<snip>
DEC Alpha but I'm not aware of what it could be.
-spc (And I have to wonder what you actually use computers for ... )
8:34 p.m.
It was thus said that the Great Richard Erlacher once stated:
so I meant that while you may have software that creates really pretty decent
code for one platform, that same source code may not produce as good a product
on another, and, in fact, may produce pretty bad code for yet another set of
hardware. There's plenty of evidence of that, at least according to people
with whom I routinely interact.
Depends upon the compiler, and also what you are trying to do.
I personally code in assembler for the MCU's I use
and occasionally use a
compiler if I have an environment where timing is not critical all the time
and where it's easier to use logic spelled out in 'C' or Pascal. That often
means that interrupt code is written in assembler while message generation or
communication code is produced by a compiler. Portability is seldom an issue
for me.
For embeded systems I don't think portability is an issue really. And
while I'm not sure if you work on embedded systems or not, if you are
writing interrupt code, then yes, I can see why you would use assembler for
that (heck, even the Linux kernel has the low level interrrupt routines in
assembler). Me, I haven't had need to write an interrrupt handler in oh,
maybe eight to ten years, but my code tends to be more of an application
level that may or may not run on different computers.
-spc (Have code that's moved from SGIs to Suns to IBMs to HPs to PCs
to Amigas to ... )
23 Apr
23 Apr
10:01 a.m.
see below, plz.
Dick
----- Original Message -----
From: "Sean 'Captain Napalm' Conner" <spc(a)conman.org>
To: <classiccmp(a)classiccmp.org>
Sent: Monday, April 22, 2002 7:34 PM
Subject: Re: Micro$oft Biz'droid Lusers (was: OT email response format)
Yes, it does, which was my point. There are limits, though.
I just finished an interrupt handler before breakfast, so I guess it hasn't
been as long for me. Of course, it's in 805x assembler ...
It was thus said that the Great Richard Erlacher once
stated:
>
> so I meant that while you may have software that creates really pretty
decent
> code for one platform, that same source code may
not produce as good a
product
> on another, and, in fact, may produce pretty bad
code for yet another set
of
> hardware. There's plenty of evidence of
that, at least according to
people
with whom I
routinely interact.
Depends upon the compiler, and also what you are trying to do.
> I personally code in assembler for the MCU's I use and occasionally use a
> compiler if I have an environment where timing is not critical all the
time
> and where it's easier to use logic spelled
out in 'C' or Pascal. That
often
> means that interrupt code is written in assembler
while message generation
or
> communication code is produced by a compiler.
Portability is seldom an
issue
for me.
For embeded systems I don't think portability is an issue really. And
while I'm not sure if you work on embedded systems or not, if you are
writing interrupt code, then yes, I can see why you would use assembler for
that (heck, even the Linux kernel has the low level interrrupt routines in
assembler). Me, I haven't had need to write an interrrupt handler in oh,
maybe eight to ten years, but my code tends to be more of an application
level that may or may not run on different computers.
-spc (Have code that's moved from SGIs to Suns to IBMs to HPs to PCs
to Amigas to ... )
22 Apr
22 Apr
8:38 a.m.
On Mon, 22 Apr 2002, Sean 'Captain Napalm' Conner wrote:
The only operating systems that I'm aware of
that were made for the DEC
Alpha were VMS (or is that OpenVMS), ULTRIX, Linux and maybe a certain
version of Windows NT. There might have been another UNIX variant made for
the DEC Alpha but I'm not aware of what it could be.
There is one more OS which I am aware of that runs on Alpha: Meditech
Magic. It is a proprietary standalone MUMPS OS which runs hospital
applications for (mostly) smaller hospitals. It boots from the same
console as Tru64/VMS but from there on is completely different.
You need specific hardware, firmware versions and the like for it to
function.
Meditech has succumbed to the one OS future and is pushing Magic
installations toward NT. There was also a version of proprietary Magic
for Data General Intel hardware that took some special BIOS but I know
next to nothing about that.
--
1:07 a.m.
At 11:35 PM 21/04/2002 -0600, Richard Erlacher wrote:
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 ...
Tru64 Unix is Compaq's (soon to be HP's) Unix offering for the Alpha
systems sold by Compaq. All new alpha based systems are supported under
Tru64. Digital sold some Alpha based systems which were Windows NT only.
Many of these systems cannot be convinced to run Tru64 (or OpenVMS for that
matter).
Huw Davies | e-mail: Huw.Davies(a)kerberos.davies.net.au
| "If God had wanted soccer played in the
| air, the sky would be painted green"
8297
days inactive
8299
days old
13 comments
6 participants
participants (6)
-
ajp166＠bellatlantic.net -
bfranchuk＠jetnet.ab.ca -
edick＠idcomm.com -
Huw.Davies＠kerberos.davies.net.au -
spc＠conman.org -
thompson＠mail.athenet.net