Difference between Unix and Linux?
Kermit Tensmeyer
"Roy Culley" <tgdc...@gd2.swissptt.ch> wrote in message
news:mfj8ha...@127.0.0.1...
> In article <3D3724A8...@cvzoom.net>,
> Donn Miller <dmmi...@cvzoom.net> writes:
> > Robert Uhl wrote:
> >> David Bristle <he...@there123.com> writes:
> >
> RMS wrote the original emacs. Gosling took it, rewrote the lisp
> interpreter (mlisp) and then sold it to Unipress who then sold it as a
> product. Unipress emacs was the first emacs I ever used way back in
> the 80's.
Not quite.. The original set of emacs was a set of TECO macros that
got handed around. enhanced set of macros were developed over time
and redistributed on the DECUS tapes.
As I recall (it was a long time ago)(76-82), some idiot in DECUS refused to
get
bugs in TECO fixed, and refused to allow anyone else to do so.
So someone decided to make a platform on which the same set
of Extended MaCroS could be ported and where the bugs could
be fixed. And of course LISP was not universally available on
all those DEC machines, so of course it had to be boot strapped.
there were not that many compilers arround at the time. DEC had
a fairly decent COBOL, and a fair to middlin Fortran, Their version
of C stunk. (which is why the WhiteSmiths C compiler took off)
Anyway as I recall, RMS was the 'author' for the LISP on the DECUS
tape sets, which made it possible to replace the TECO macro's with
a real editing tools.
And I think that the popularity of the LISP editor is one of the
reasons
that DEC finally built EDT
>
> It was this taking of RMS's free emacs and making it into a commercial
> product that was one of the main reasons for the GPL. It is also the
> reason why he rewrote GNU emacs from scratch.
could be.
dk
developed by Kernigan and Ritchie while working for Ma Bell and the latter was
developed by Linux Torvald as an independent project with the idea of making
something that is not monolithic.
Dave
Kermit Tensmeyer wrote:
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Charles Richmond
>
> I always thought the difference betweem Unix and Linux is that the former was
> developed by Kernigan and Ritchie while working for Ma Bell and the latter was
> developed by Linux Torvald as an independent project with the idea of making
> something that is not monolithic.
>
sure that Brian Kernighan contributed to the effort... Of course,
after it got started, lots of A.T.& T. people contributed utilities.
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
Floyd Davidson
>I always thought the difference betweem Unix and Linux is that the former was
>developed by Kernigan and Ritchie while working for Ma Bell and the latter was
>developed by Linux Torvald as an independent project with the idea of making
>something that is not monolithic.
>
>Dave
Unix indeed originated at Bell Labs. But it was rewritten
several times before it ever landed on a typical PC! It was
rewritten by the original crew at Bell Labs, and also by people
at UC Berkeley, by people at several major companies such as Sun
Microsystems, SCO, and Hewlett Packard, as well as by AT&T
people who were not part of Bell Labs.
Bell Labs was certainly not directly responsible for any of the
Unix OS's (even the ones sold by AT&T) that eventually became
widely available either as commercial products or as Open
Software.
One implementation of Unix, called Linux, was written by Linus
Torvalds.
But, what is the relationship between anything above and anything
below???? (And, of course Linux _is_ monolithic.)
>Kermit Tensmeyer wrote:
--
Floyd L. Davidson <http://www.ptialaska.net/~floyd>
Ukpeagvik (Barrow, Alaska) fl...@barrow.com
Ross Simpson
> I always thought the difference betweem Unix and Linux is that the
former was
> developed by Kernigan and Ritchie while working for Ma Bell and the
latter was
> developed by Linux Torvald as an independent project with the idea
of making
> something that is not monolithic.
I always thought one the main differences between Unix & Linux is the
age. Unix was written (by Bell Laboratories) for a mainframe in the
1970's.
The first microcomputers I've read about to support Unix was a 68xxx
type (don't know if that included Mac based PC's), perhaps 10-13 years
after Unix was originally written.
But Linux would have all the modern features which obviously the
original Unix (or even Linux when it may of first came out) wouldn't
have.
Regards,
Ross.
Dave
> I always thought the difference betweem Unix and Linux is that the former was
> developed by Kernigan and Ritchie while working for Ma Bell and the latter was
> developed by Linux Torvald as an independent project with the idea of making
> something that is not monolithic.
By "monolithic" are you talking kernel design? I was always under the
impression that Linus developed Linux simply because he was curious what
the 386 was capable of.
--
David Griffith
dgr...@cs.csubak.edu
Radovan Garabik
: I always thought the difference betweem Unix and Linux is that the former was
: developed by Kernigan and Ritchie while working for Ma Bell and the latter was
: developed by Linux Torvald as an independent project with the idea of making
: something that is not monolithic.
But linux _was_ monolithic...
only current versions (since 2.2 or so) consist of several
concurrently working kernel threads (but still the kernel design
can be considered monolithic)
OTOH, Minix, which inspired Linus, had a microcernel design.
--
-----------------------------------------------------------
| Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik |
| __..--^^^--..__ garabik @ fmph . uniba . sk |
-----------------------------------------------------------
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
Joel Mayes
Hash: SHA1
In a moment of clarity Radovan Garabik had the following
epiphany
> But linux _was_ monolithic... only current versions
> (since 2.2 or so) consist of several concurrently
> working kernel threads (but still the kernel design can
> be considered monolithic)
>
> OTOH, Minix, which inspired Linus, had a microcernel
> design.
>
WOW. something crossposted to COLA which isn't a troll!
My understanding of the history was that Linus had several
major problems with the design of Minix, and microkernel
design in general.
Cheers
Joel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9PSjoWxU5n0eFaBkRAgQwAJ9jdEALaMGZZS9awqLcpYJjKDHn3ACgjrTO
33md6Ewv4NgO+InmOi5pk6o=
=+fV/
-----END PGP SIGNATURE-----
--
Sourcemage GNU/Linux /~\ ASCII Ribbon campaign
Linux so advanced it may as well be magic \_/ stop HTML mail and news
x11 & doc section maintainer / \
http://search.keyserver.net:11371/pks/lookup?op=vindex&search=0x47856819
Pete Fenelon
>> I always thought one the main differences between Unix & Linux is the
>> age. Unix was written (by Bell Laboratories) for a mainframe in the
>> 1970's.
>
Unix was written on the PDP-7. The PDP-11 was the first rewrite (I don't
think they used the term "port" back then). Very definitely a mini. :)
pete
--
pe...@fenelon.com "serious sport has nothing to do with fair play" - orwell
Ross Simpson
>
> >> I always thought one the main differences between Unix & Linux is
the
> >> age. Unix was written (by Bell Laboratories) for a mainframe in
the
> >> 1970's.
> >
> > The PDP-11 isn't a mainframe. It's a mini.
>
> Unix was written on the PDP-7. The PDP-11 was the first rewrite (I
don't
> think they used the term "port" back then). Very definitely a mini.
:)
I was always under the impression that Mini Computers came out later
on. But then I'm only human! :-)
Regards,
Ross.
Doc
> They all laughed when "Ross Simpson"
><rosssimpson@my_spammers_address(optusnet).com.au> said...
>>
>> I always thought one the main differences between Unix & Linux is the
>> age. Unix was written (by Bell Laboratories) for a mainframe in the
>> 1970's.
>
It's amazing how many professionals don't know the difference. I have
a pair of 11/93s that I got more or less directly from the original
owners. The operators/techs who had been running the pair [1] called
them a mainframe.
I think the current mainframe criteria are:
A) Absence of Windows/NT/MS
B) Wheels
[1] They were the main & backup controller modules for a huge automated
warehouse, and were decommissioned in August of 2001. I was told that if
Compaq had been able to continue support, they would probably not have
been removed from service,
Doc
Steve O'Hara-Smith
dk <dkan...@acronet.net> wrote:
D> I always thought the difference betweem Unix and Linux is that the
D> former was developed by Kernigan and Ritchie while working for Ma Bell
D> and the latter was developed by Linux Torvald as an independent project
D> with the idea of making something that is not monolithic.
I don't recall anything about not being monolithic in Linux. It was
more about replacing the Minix kernel with something that took advantage
of the 386, it has grown a bot since then. You may be thinking of the Mach
kernel.
--
C:>WIN | Directable Mirrors
The computer obeys and wins. |A Better Way To Focus The Sun
You lose and Bill collects. | licenses available - see:
| http://www.sohara.org/
Peter Ibbotson
news:20020723075407....@eircom.net...
> On Mon, 22 Jul 2002 21:42:56 -0500
> dk <dkan...@acronet.net> wrote:
>
> D> I always thought the difference betweem Unix and Linux is that the
> D> former was developed by Kernigan and Ritchie while working for Ma Bell
> D> and the latter was developed by Linux Torvald as an independent project
> D> with the idea of making something that is not monolithic.
>
> I don't recall anything about not being monolithic in Linux. It was
> more about replacing the Minix kernel with something that took advantage
> of the 386, it has grown a bot since then. You may be thinking of the Mach
> kernel.
See url below for fight between Tanenbaum & Linus (starting at around msg
12)
http://groups.google.com/groups?threadm=12595%40star.cs.vu.nl
--
Work pet...@lakeview.co.uk.plugh.org | remove magic word .org to reply
Home pe...@ibbotson.co.uk.plugh.org | I own the domain but theres no MX
Christopher Browne
> On Mon, 22 Jul 2002 21:42:56 -0500
> dk <dkan...@acronet.net> wrote:
>
> D> I always thought the difference betweem Unix and Linux is that the
> D> former was developed by Kernigan and Ritchie while working for Ma Bell
> D> and the latter was developed by Linux Torvald as an independent project
> D> with the idea of making something that is not monolithic.
>
> I don't recall anything about not being monolithic in Linux. It was
> more about replacing the Minix kernel with something that took advantage
> of the 386, it has grown a bot since then. You may be thinking of the Mach
> kernel.
The memory may have been of the Torvalds/Tanenbaum flame war, which
involved such still-entertaining gems as:
"I still maintain the point that designing a monolithic kernel in
1991 is a fundamental error. Be thankful you are not my student.
You would not get a high grade for such a design :-)" -- Andrew
Tanenbaum to Linus Torvalds
"Anyone who says you can have a lot of widely dispersed people hack
away on a complicated piece of code and avoid total anarchy has
never managed a software project." Andrew Tanenbaum, 1992.
"Of course 5 years from now that will be different, but 5 years from
now everyone will be running free GNU on their 200 MIPS, 64M
SPARCstation-5." -- Andrew Tanenbaum, 1992.
"I am aware of the benefits of a micro kernel approach. However,
the fact remains that Linux is here, and GNU isn't --- and people
have been working on Hurd for a lot longer than Linus has been
working on Linux." -- Ted T'so, 1992.
Ten years have passed; many of the points still ring as true today as
they did back then...
--
(reverse (concatenate 'string "gro.mca@" "enworbbc"))
http://cbbrowne.com/info/wp.html
Do infants have as much fun in their infancy as adults do in their
adultery?
GeneralPF
> Quoth Steve O'Hara-Smith <ste...@eircom.net>:
>> On Mon, 22 Jul 2002 21:42:56 -0500
>> dk <dkan...@acronet.net> wrote:
>>
>> D> I always thought the difference betweem Unix and Linux is that the
>> D> former was developed by Kernigan and Ritchie while working for Ma Bell
>> D> and the latter was developed by Linux Torvald as an independent project
>> D> with the idea of making something that is not monolithic.
>>
>> I don't recall anything about not being monolithic in Linux. It was
>> more about replacing the Minix kernel with something that took advantage
>> of the 386, it has grown a bot since then. You may be thinking of the Mach
>> kernel.
>
> The memory may have been of the Torvalds/Tanenbaum flame war, which
> involved such still-entertaining gems as:
>
> "I still maintain the point that designing a monolithic kernel in
> 1991 is a fundamental error. Be thankful you are not my student.
> You would not get a high grade for such a design :-)" -- Andrew
> Tanenbaum to Linus Torvalds
>
> "Anyone who says you can have a lot of widely dispersed people hack
> away on a complicated piece of code and avoid total anarchy has
> never managed a software project." Andrew Tanenbaum, 1992.
We don't know if this is true. The actual number of people who have the
authority to commit code to the Linux kernel is less than a "lot".
Same with Mozilla, etc.
Christopher Browne
There are quite a lot of "committers" for FreeBSD, so that Linux, with
a "single despot," isn't anywhere _near_ the best example.
Nonetheless, there's quite a lot of anarchy as you get away from the
specifics of the software Linus Torvalds manages.
The fact that there's a continuing thread where some keep demanding
that it's called "GNU/Linux" demonstrates that there's a lot of widely
dispersed people hacking away...
--
(concatenate 'string "cbbrowne" "@cbbrowne.com")
http://cbbrowne.com/info/spreadsheets.html
Would-be National Mottos:
Poland: "We probably would have had a happier history if we were
between Canada and Mexico, not Germany and Russia."
GeneralPF
Sure there are a lot of "widely dispersed people hacking away" but every
patch is committed by a *very* *small* group of priveleged people.
So the Linux kernel doesn't fit Tanenbaum's scenario.
Sam Holden
> On 23 Jul 2002 20:45:36 GMT, Christopher Browne assert()ed:
>> The world rejoiced as GeneralPF <Gene...@nitrogen.ertw.com> wrote:
>>> On 23 Jul 2002 19:19:03 GMT, Christopher Browne assert()ed:
>>>> "Anyone who says you can have a lot of widely dispersed people hack
>>>> away on a complicated piece of code and avoid total anarchy has
>>>> never managed a software project." Andrew Tanenbaum, 1992.
>>>
> Sure there are a lot of "widely dispersed people hacking away" but every
> patch is committed by a *very* *small* group of priveleged people.
> So the Linux kernel doesn't fit Tanenbaum's scenario.
The quote mentions "a lot of widely dispresed people hack[ing] away",
and "a complicated piece of code". It implies if you have both of those
factors you will be unable to "avoid total anarchy". Patch committing
priveledges aren't mentioned.
Can you provide the context which shows that Tanenbaum was assumming that
a significant number of the hackers would have committing proviledges?
Since Linux seems complicated enough, and has enough people hacking away
that the scenario as quoted seems to be fulfilled (except that 'total
anarchy' hasn't occurred).
--
Sam Holden
GeneralPF
Yeah, but if there are people working on it without *write* access to it,
they're just "virtually" working on it, and the committers are their
surrogates.
In essence, the committers are the ones working on it, and the
writers are the ones supplying them with code.
Clearly, Tanenbaum was assuming the people working on it
*had* *the* *potential* *to* *cause* *anarchy*, which a person
without commit access does *not* have.
Brian Inglis
<pe...@fenelon.com> wrote:
>In alt.folklore.computers mathew <dev...@iprimus.c0m.au> wrote:
>>> I always thought one the main differences between Unix & Linux is the
>>> age. Unix was written (by Bell Laboratories) for a mainframe in the
>>> 1970's.
>>
>> The PDP-11 isn't a mainframe. It's a mini.
>
>Unix was written on the PDP-7.
In PDP-7 assembler.
>The PDP-11 was the first rewrite (I don't
In PDP-11 C.
>think they used the term "port" back then). Very definitely a mini. :)
When C had just replaced assembler for writing OSes?
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian....@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply
tos...@aol.com ab...@aol.com ab...@yahoo.com ab...@hotmail.com ab...@msn.com ab...@sprint.com ab...@earthlink.com ab...@cadvision.com ab...@ibsystems.com u...@ftc.gov
spam traps
Sam Holden
From reading the message the quote came from I think Tanenbaum was
referring to the fact that Linus was licensing Linux so that anyone
could release their own version of it with their own modifications
and distribute it (not as patches to the 'official' version but as a
whole). That was the key difference between the minix and linux terms
for distributing modifications after all (with respect to modifications).
And that has happened. There are plenty of linux kernels which are not the
'official' ones. From the various older kernel versions, to the various
-<initials here> versions from various kernel hackers, to things like
user-mode linux. They are sometimes distributed as patches, but also
sometimes as complete kernels in and of themselves.
Instead of 'total anarchy' what we seem to have got is a bunch of kernels
trying out different things, and every so often the 'official' kernel will
swallow up the changes because they are considered useful and good enough.
The various distributions like RedHat often use a patched kernel as well,
their ability to distribute something other than the official one hasn't
caused 'total anarchy' either.
Tenenbaum seemed to thin that you would end up with complete confusion
as to what was and what wasn't linux. That there would be a differernt
version for every kernel hacker and they would be incompatable in some
way. And hence from a users point of view it would be 'total anarchy'
and unusable. Imagine if your video card was supported by Billux and
your sound card was supported by Tedux and your motherboard by Fredux,
and those three versions had diverged so that they were incompatable
with one another. That would be anarchy to me, and would make Linux
essentially useless.
It hasn't happened. I suspect because people like Linux Torvalds and
Alan Cox have managed to keep enough people happy enough that enough
people can live with their code not always being accepted. They don't
keep everyone happy as reading the kernel mailing list will show :)
--
Sam Holden
Dennis Ritchie
...
> Unix indeed originated at Bell Labs. But it was rewritten
> several times before it ever landed on a typical PC! It was
> rewritten by the original crew at Bell Labs, and also by people
> at UC Berkeley, by people at several major companies such as Sun
> Microsystems, SCO, and Hewlett Packard, as well as by AT&T
> people who were not part of Bell Labs.
>
> Bell Labs was certainly not directly responsible for any of the
> Unix OS's (even the ones sold by AT&T) that eventually became
> widely available either as commercial products or as Open
> Software.
This thread has carried on a bit further since Davidson's
posting, but these paragraphs here aren't quite true in
some sense, or at least deserve some amplification.
There was plenty of work on Unix (including real
commercial distribution after 1984) in Bell Labs
outside of the original research group, which may
be the group Davidson was concentrating on. How much
it was "rewritten" as opposed to "adapted" (particularly
in the early years) can be debated. In later years
UCB and presumably the manufacturers did do considerable
rewriting--Berkeley (eventually) specifically to detach
themselves from AT&T licensing. But certainly in the
early 80s the offerings (AT&T's and Sun's and any others)
were based on the original code. The one real exception
I can think of then was Coherent.
However, even by 1984 (as documented in the Oct 1984 AT&T
Bell Labs Tech J) there had been many "ports,", including
on the one hand the Intel 8086, on the other to S/370
and the Univac 1100.
The latter were of course mainframes, but as others have
pointed out, the first versions were on the PDP-7
(with 8K 18-bit words) and the PDP-11 (our first had
12K 16-bit words). Indeed, not mainframes even by
then-contemporary standards.
Dennis
Floyd Davidson
>Pete Fenelon <pe...@fenelon.com> wrote:
>>In alt.folklore.computers mathew <dev...@iprimus.c0m.au> wrote:
>>
>>Unix was written on the PDP-7.
>
>In PDP-7 assembler.
>
>>The PDP-11 was the first rewrite (I don't
>
>In PDP-11 C.
See Dennis's homepage,
<http://cm.bell-labs.com/cm/cs/who/dmr/hist.html>
<http://cm.bell-labs.com/cm/cs/who/dmr/chist.html>
The PDP-11 port was first done in PDP-11 assembler by Ken
Thompson. Only a few programs were written in B. The first PDP-11
was acquired in 1970 and became fully functional in December of
that year, at which point UNIX was ported to it.
Development of C began in 1971, but the rewrite of UNIX in C was
not done until 1973. (Ken Thompson apparently made an effort at
it in 1972, but C wasn't yet up to the task...)
>>think they used the term "port" back then). Very definitely a mini. :)
>
>When C had just replaced assembler for writing OSes?
It may have taken awhile though... See,
<http://cm.bell-labs.com/cm/cs/who/dmr/firstport.html>
Which is described as a 1976 memo about "the idea of porting
Unix to a new architecture", but while it uses the term
"portability" several times, "port" is absent.
Floyd Davidson
That matches what I intended to convey. My point was that
initially the "rewriting" was at AT&T, but eventually it
involved a number of people and places, and the significance of
what was rewritten varies just as greatly.
Certainly though, all Unix varieties depend on the original
concepts, if not the original code, that you and Ken Thompson
developed throughout the 1970's. The variations have included
versions that are mostly AT&T originated code and others which
are completely independent code intended to implement your
concepts and functionality.
I'm thinking of "Unix" as more the concept of the Unix OS that
came from AT&T, rather than the specific implementations of it
from the research group at Bell Labs. (And that of course may
be significantly different than the view you or Ken Thompson
might have!) I am perhaps influenced by having worked all of my
life with many other concepts that originated, and often to some
degree were first implemented too, at Bell Labs to later be
manufactured by Western Electric and then by others. Hence, I
see Linux as a Unix, just as I see Alcatel T1 carrier equipment
as being a T1.
>However, even by 1984 (as documented in the Oct 1984 AT&T
>Bell Labs Tech J) there had been many "ports,", including
>on the one hand the Intel 8086, on the other to S/370
>and the Univac 1100.
>
>The latter were of course mainframes, but as others have
>pointed out, the first versions were on the PDP-7
>(with 8K 18-bit words) and the PDP-11 (our first had
>12K 16-bit words). Indeed, not mainframes even by
>then-contemporary standards.
For whatever reasons, today a lot of people view virtually any
pre-microchip computer as a "mainframe", and it is not uncommon
to see claims that Unix was "designed for mainframes" from the
start. Recently one Usenet poster claimed, when the limitations
of the PDP machines was pointed out, that even if the PDP-7 and
PDP-11 were not mainframes, Unix still evolved from work on
Multics for the GE-645, and therefore it is "mainframe in
origination"! :-)
Rupert Pigott
news:87adoho...@barrow.com...
[SNIP]
> For whatever reasons, today a lot of people view virtually any
> pre-microchip computer as a "mainframe", and it is not uncommon
> to see claims that Unix was "designed for mainframes" from the
> start. Recently one Usenet poster claimed, when the limitations
> of the PDP machines was pointed out, that even if the PDP-7 and
> PDP-11 were not mainframes, Unix still evolved from work on
> Multics for the GE-645, and therefore it is "mainframe in
> origination"! :-)
There was a thread a while back discussing the origins of the
word mainframe. It seemed to pretty much concurr with what I
guessed, the word originates from the main structural entity
that the CPU is physically housed/hung-off (eg : circuitry was
mounted on "frames")...
So I'd argue that the word mainframe is an abusage in itself
unless someone can come up with an alternative explaination of
the origin of the word. :)
Cheers,
Rupert
Chris Hedley
> For whatever reasons, today a lot of people view virtually any
> pre-microchip computer as a "mainframe", and it is not uncommon
> to see claims that Unix was "designed for mainframes" from the
> start.
It seems a fair number of people refer, perhaps not unreasonably,
to any big, expensive timesharing system as a "mainframe."[1] I've
also seen that encompass smallish Sun servers, though, which is
really pushing things a bit, although I daresay in some cases this
is an attempt as "snob value."
[1] I know that the two aren't necessarily synonymous, but you get
the idea. Maybe it's time for the biannual posting of someone's
"it might be a mainframe if..." list. :)
Chris.
--
"If the world was an orange it would be like much too small, y'know?" Neil, '84
http://cbh.paunix.org My stuff, including genealogy, other things, etc
http://www.paunix.org SDF Public Access UNIX: UNIX accounts and webspace!
Kermit Tensmeyer
"Dennis Ritchie" <d...@bell-labs.com> wrote in message
news:3D3E214F...@bell-labs.com...
> Floyd Davidson wrote:
> ...
> > Unix indeed originated at Bell Labs. But it was rewritten
> > several times before it ever landed on a typical PC! It was
> > rewritten by the original crew at Bell Labs, and also by people
> > at UC Berkeley, by people at several major companies such as Sun
> > Microsystems, SCO, and Hewlett Packard, as well as by AT&T
> > people who were not part of Bell Labs.
> >
> > Bell Labs was certainly not directly responsible for any of the
> > Unix OS's (even the ones sold by AT&T) that eventually became
> > widely available either as commercial products or as Open
> > Software.
> ...
>
> This thread has carried on a bit further since Davidson's
> posting, but these paragraphs here aren't quite true in
> some sense, or at least deserve some amplification.
Just to point out, that this thread started as a response to
a troll, who insists that nothing prior to the Unix95 spec
can be termed Unix. In fact (his claim), all such forms
are unix-like and not Unix. And as such should not
be discussed as Unix.
of course we disagree.. V6, V7, bsd are
real unix....
but :-) HP-UX, Ultrix, Solaris, AIX ?
these we're still not sure of...
J. Clarke
says...
> On Tue, 23 Jul 2002 19:35:50 +1000, mathew <dev...@iprimus.c0m.au> wrote:
> > They all laughed when "Ross Simpson"
> ><rosssimpson@my_spammers_address(optusnet).com.au> said...
> >>
> >> I always thought one the main differences between Unix & Linux is the
> >> age. Unix was written (by Bell Laboratories) for a mainframe in the
> >> 1970's.
> >
> > The PDP-11 isn't a mainframe. It's a mini.
>
> It's amazing how many professionals don't know the difference. I have
> a pair of 11/93s that I got more or less directly from the original
> owners. The operators/techs who had been running the pair [1] called
> them a mainframe.
> I think the current mainframe criteria are:
> A) Absence of Windows/NT/MS
> B) Wheels
The distinction has gotten kind of fuzzy lately. I mean what's a P/390?
Do you make the distinction by physical size, by architecture, by
capacity, by performance, by historical market placement, or what?
> [1] They were the main & backup controller modules for a huge automated
> warehouse, and were decommissioned in August of 2001. I was told that if
> Compaq had been able to continue support, they would probably not have
> been removed from service,
>
> Doc
>
--
--
--John
Reply to jclarke at ae tee tee global dot net
(used to be jclarke at eye bee em dot net)
Shmuel (Seymour J.) Metz
In <slrnajqr0...@george.home.org>, on 07/23/2002
at 02:45 PM, Doc <d...@elsewhere.com> said:
> It's amazing how many professionals don't know the difference.
Madison Avenue systematically abused the word to the point where it
lost its meaning entirely and now has no more semantic content that
"whiter than white". The original definition was in terms of word
lengh, price and size. Basically, to be a mini it had to be light
enough for one person to move it, have a short word size and cost in
the low thens of thousands (US$). There was also a word "midi" used
for the 24-bit machines.
When people starting referring to the PDP-6, PDP-10 and VAX-11/780 as
minicomputers, I wrote off the word as useless.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2, Team OS/2, Team PL/I
Any unsolicited commercial junk E-mail will be subject to legal
action. I reserve the right to publicly post or ridicule any
abusive E-mail.
I mangled my E-mail address to foil automated spammers; reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org
Shmuel (Seymour J.) Metz
In <ahkf9g$tk4lm$1...@ID-125932.news.dfncis.de>, on 07/23/2002
at 08:45 PM, Christopher Browne <cbbr...@acm.org> said:
>The fact that there's a continuing thread where some keep demanding
>that it's called "GNU/Linux" demonstrates that there's a lot of
>widely dispersed people hacking away...
No, it just demonstrates that a typical Linux distribution includes a
lot of GNU programs. Of course, it also includes a lot of programs
that know not RMS, so I prefer just calling them Linux distributions
and not mentioning GNU at all.
Shmuel (Seymour J.) Metz
In <87adoho...@barrow.com>, on 07/24/2002
at 12:48 AM, Floyd Davidson <fl...@ptialaska.net> said:
>Unix still evolved from work on
>Multics for the GE-645,
Not really; the heart and soul of Multics was the memory-mapped file
system, and Unix was written for a machine that could not support
that. Just about everything that was characteristic of Multics was
missing from Unix.
Shmuel (Seymour J.) Metz
In <tv4sjugbh9qfjlc4o...@4ax.com>, on 07/24/2002
at 02:44 AM, Brian Inglis <Brian....@SystematicSw.ab.ca> said:
>When C had just replaced assembler for writing OSes?
Where? MCP was written in ESPOL and DC ALGOL. Multics was written in
PL/I. DEC had BLISS. IBM was moving in the direction of BSL. The
original Unix was bucking the trend by using assembler.
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> For whatever reasons, today a lot of people view virtually any
> pre-microchip computer as a "mainframe", and it is not uncommon
> to see claims that Unix was "designed for mainframes" from the
> start. Recently one Usenet poster claimed, when the limitations
> of the PDP machines was pointed out, that even if the PDP-7 and
> PDP-11 were not mainframes, Unix still evolved from work on
> Multics for the GE-645, and therefore it is "mainframe in
> origination"! :-)
>
to Multics. I would *not* say that the medicine was a disease,
just because the medicine was created *because* of the disease.
IMHO the preconcieved notions of many of the neophyte computer
people are more dear to them...than knowing the actual facts.
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
Charlie Gibbs
(J. Clarke) writes:
>In article <slrnajqr0...@george.home.org>, d...@elsewhere.com
>says...
>
>> I think the current mainframe criteria are:
>> A) Absence of Windows/NT/MS
>> B) Wheels
>
>The distinction has gotten kind of fuzzy lately. I mean what's a
>P/390? Do you make the distinction by physical size, by architecture,
>by capacity, by performance, by historical market placement, or what?
I still vote for architecture. A mainframe's terminals run in block
mode, usually using a synchronous protocol, while a mini's terminals
use the async that we all know and love nowadays. Mainframe OSes
tend to be optimized for batch operations, while minis do better at
interactive tasks. Thus I'd consider the Univac 9300 I started on
to be a small mainframe, while a much larger PDP-10 installation
would be a mini. Conceptually the 9300 has a lot more in common
with, say, a 360/85 than with a PDP-10, while the -10 has more in
common with a desktop PDP-8 than with big IBM iron.
--
cgi...@kltpzyxm.invalid (Charlie Gibbs)
I'm really at moc.subyks if you read it the right way.
Top-posted messages will probably be ignored. See RFC1855.
Alan Barclay
Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
>I still vote for architecture. A mainframe's terminals run in block
>mode, usually using a synchronous protocol, while a mini's terminals
>use the async that we all know and love nowadays. Mainframe OSes
The mainframe I use nowadays all the users connect using TCP/IP.
Right now the majority are using 3270 emulators, but most of my
work is done using a 'normal' telnet client.
Dowe Keller
> In <ahkf9g$tk4lm$1...@ID-125932.news.dfncis.de>, on 07/23/2002
> at 08:45 PM, Christopher Browne <cbbr...@acm.org> said:
>
> >The fact that there's a continuing thread where some keep demanding
> >that it's called "GNU/Linux" demonstrates that there's a lot of
> >widely dispersed people hacking away...
>
> No, it just demonstrates that a typical Linux distribution includes a
> lot of GNU programs. Of course, it also includes a lot of programs
> that know not RMS, so I prefer just calling them Linux distributions
> and not mentioning GNU at all.
I vote we call them GNU/BSD/MIT/etc./Linux systems ;-).
--
do...@sierratel.com <http://www.sierratel.com/dowe>
Your job is being a professor and researcher: That's one hell of a good excuse
for some of the brain-damages of minix.
(Linus Torvalds to Andrew Tanenbaum)
Toby Thain
> In <slrnajqr0...@george.home.org>, on 07/23/2002
> at 02:45 PM, Doc <d...@elsewhere.com> said:
>
>
>> It's amazing how many professionals don't know the difference.
>
>
>
> When people starting referring to the PDP-6, PDP-10 and VAX-11/780 as
> minicomputers, I wrote off the word as useless.
>
What's an 11/750 then? It has castors but is a bugger to move anywhere
you can't roll it.
Toby
jmfb...@aol.com
"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>(J. Clarke) writes:
>
>>In article <slrnajqr0...@george.home.org>, d...@elsewhere.com
>>says...
>>
>>> I think the current mainframe criteria are:
>>> A) Absence of Windows/NT/MS
>>> B) Wheels
>>
>>The distinction has gotten kind of fuzzy lately. I mean what's a
>>P/390? Do you make the distinction by physical size, by architecture,
>>by capacity, by performance, by historical market placement, or what?
>
>I still vote for architecture. A mainframe's terminals run in block
>mode, usually using a synchronous protocol, while a mini's terminals
>use the async that we all know and love nowadays. Mainframe OSes
>tend to be optimized for batch operations, while minis do better at
>interactive tasks. Thus I'd consider the Univac 9300 I started on
>to be a small mainframe, while a much larger PDP-10 installation
>would be a mini.
Harumph.. ;-)
> .. Conceptually the 9300 has a lot more in common
>with, say, a 360/85 than with a PDP-10, while the -10 has more in
>common with a desktop PDP-8 than with big IBM iron.
Interesting. I wouldn't consider IBM's batch a main frame
function.
/BAH
Subtract a hundred and four for e-mail.
Alan T. Bowler
> In article <1218.970T1...@kltpzyxm.invalid>,
> Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
> >I still vote for architecture. A mainframe's terminals run in block
> >mode, usually using a synchronous protocol, while a mini's terminals
> >use the async that we all know and love nowadays. Mainframe OSes
Only some mainframe terminals ran in block mode.
Dumb ASCII async terminals were the usual choice
for timesharing use on non-IBM hardware.
Anne & Lynn Wheeler
> Only some mainframe terminals ran in block mode.
> Dumb ASCII async terminals were the usual choice
> for timesharing use on non-IBM hardware.
i added tty/ascii support to cp/67 back when undergraduate in late
'60s. IBM picked up the code and shipped it in the product. it had a
sort of design glitch ... and later when somebody at MIT modified the
code ... it resulted in numerous kernel crashes that day.
they were supported in half-duplex mode by the (ibm) 2702 terminal
controller which recognized certain line-end characters and generated
interrupt to the processor when those characters were encountered.
at the university, we ran into some issues with the 2702 terminal
controller and a couple of us started a project where we built a
terminal controller starting with interdata/3 and reverse engineering
the ibm channel interface and building our own board to interface to
the ibm mainframe channel ... supposedly credited with originated the
ibm pcm controller business:
http://www.garlic.com/~lynn/subtopic.html#360pcm
the interdata/3 supported the tty terminals in full duplex and then
played some games mapping that to half-duplex for the 2702 controller
emulation. later, it was enhanced to be a combination of interdata/4
with interdata/3 dedicated to line-scanner function.
I believe the use of the interdata as termianl controller was then
expanded to other mainframes (not just ibm). Also, perkin/elmer
eventually bought it up ... and they were sold under the perkin/elmer
brand. I ran into one 5-6 years ago in major transaction processing
datacenter still handling heavy traffic load.
there was the "yale iup" for the series/1 in the '80s which also
provided full-duplex ascii support for tty terminals to aix/370 (aka
the port of ucla locus to 370 and ps/2 and released as ibm product).
--
Anne & Lynn Wheeler | ly...@garlic.com - http://www.garlic.com/~lynn/
Brian Inglis
<spam...@library.lspace.org.invalid> wrote:
>
>In <tv4sjugbh9qfjlc4o...@4ax.com>, on 07/24/2002
> at 02:44 AM, Brian Inglis <Brian....@SystematicSw.ab.ca> said:
>
>>When C had just replaced assembler for writing OSes?
^ portable
>Where? MCP was written in ESPOL and DC ALGOL. Multics was written in
>PL/I. DEC had BLISS. IBM was moving in the direction of BSL. The
>original Unix was bucking the trend by using assembler.
Correction by Floyd noted and thanked. Please note mod to
original statement above. Heard of IBM PL/S but not BSL?
AFAICT all these other SILs were wedded to a single architecture
if not a machine type, and possibly a single compiler with a
highly customized run time system for OS interfacing.
I think that, at the time, given memory constraints, writing
mainframe OSes (TOS/DOS/MFT/MVT/OS, VM/CP, TOPS-10) in assembler
was a good engineering choice, and even more so for mini OSes.
Brian Inglis
<spam...@library.lspace.org.invalid> wrote:
>
>In <slrnajqr0...@george.home.org>, on 07/23/2002
> at 02:45 PM, Doc <d...@elsewhere.com> said:
>
>> It's amazing how many professionals don't know the difference.
>
>Madison Avenue systematically abused the word to the point where it
>lost its meaning entirely and now has no more semantic content that
>"whiter than white". The original definition was in terms of word
>lengh, price and size. Basically, to be a mini it had to be light
>enough for one person to move it, have a short word size and cost in
>the low thens of thousands (US$). There was also a word "midi" used
>for the 24-bit machines.
I think the bus/channel I/O distinction was also quite a
significant difference between the types.
The PDP-15 was definitely a scientific mini (32K 18 bit words,
1MB disk, paper tape, cards) but not exactly light and cost >
GBP100,000 AFAIR.
And a fully loaded PDP-11/70 mini with all the normal peripherals
was about the same size and cost as a small mainframe or VAX, and
performed about the same amount of work.
>When people starting referring to the PDP-6, PDP-10 and VAX-11/780 as
>minicomputers, I wrote off the word as useless.
The VAX-11/780 certainly was priced and performed like a high end
mini -- Massbus and Unibus peripherals just like the other 11s --
and the 11/750 was probably not much better than a similarly
equipped 11/45.
Richard Steiner
"Alan T. Bowler" <atbo...@thinkage.ca> spake unto us, saying:
>Only some mainframe terminals ran in block mode.
>Dumb ASCII async terminals were the usual choice
>for timesharing use on non-IBM hardware.
Not in UNIVAC 1100-land. Even "modern" Unisys Clearpath IX mainframes
tend to use block-mode UTS terminals.
--
-Rich Steiner >>>---> http://www.visi.com/~rsteiner >>>---> Eden Prairie, MN
OS/2 + BeOS + Linux + Win95 + DOS + PC/GEOS = PC Hobbyist Heaven! :-)
Applications analyst/designer/developer (13 yrs) seeking employment.
See web site in my signature for current resume and background.
Christopher Browne
> I think that, at the time, given memory constraints, writing
> mainframe OSes (TOS/DOS/MFT/MVT/OS, VM/CP, TOPS-10) in assembler was
> a good engineering choice, and even more so for mini OSes.
In addition, people actually did have the concept of "quasi-portable
assembly language" back then: ML/I and STAGE2 were notable as macro
assemblers where a subset would get ported into a specific processor's
assembly language, and then represent a bootstrap to allow deploying
the whole language.
http://members.shaw.ca/parz/ML1.html
I think that part of what has happened is that people have gotten
sufficiently helpless over the years that they get weak in the knees
at the very thought of having to deal with assembly language.
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://cbbrowne.com/info/multiplexor.html
It's always darkest just before it gets pitch black.
Karl Kleine
> In an attempt to throw the authorities off his trail, Brian Inglis <Brian....@SystematicSw.ab.ca> transmitted:
>> I think that, at the time, given memory constraints, writing
>> mainframe OSes (TOS/DOS/MFT/MVT/OS, VM/CP, TOPS-10) in assembler was
>> a good engineering choice, and even more so for mini OSes.
> In addition, people actually did have the concept of "quasi-portable
> assembly language" back then: ML/I and STAGE2 were notable as macro
> assemblers where a subset would get ported into a specific processor's
> assembly language, and then represent a bootstrap to allow deploying
> the whole language.
> http://members.shaw.ca/parz/ML1.html
[....]
The original ML/1 manual is available on my history page
http://www.fh-jena.de/~kleine/history
as well as an introductory paper. Both are pdf files files
scanned from original old manuals.
Under the link to Herzog's ML/1 page, quoted by Browne above,
you will find a html version of the manual, as well as an
implementation in C (source) and a win32 binary.
Karl Kleine
________________________________________________________
Prof. Karl Kleine http://www.fh-jena.de/~kleine
Fachhochschule Jena kle...@fh-jena.de
Carl-Zeiss-Promenade 2 +49-3641-205-502 [fax -503]
D-07745 Jena, Germany
Alan T. Bowler
>
> The VAX-11/780 certainly was priced and performed like a high end
> mini -- Massbus and Unibus peripherals just like the other 11s --
A CS prof walked through our machine room giving a tour.
He pointed to the Honeywell DPS-8/49 and disparaginglly referred
to it as a mainframe, and pointed to the VAX 780 and proudly
proclaimed it a mini.
Both machines were fairly new hardware (although the Honeywell was
continuing to use some older peripherals), both cost the same,
both ran CPU benchmarks about the same speed.
I concluded the Vax was a mainframe.
The main difference was that the Gcos system normally ran two
to three times the number of concurrent users.
H.Vlems
"Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid> schreef in
bericht news:3d3ee39d$3$fuzhry+tra$mr2...@news.patriot.net...
>
> In <slrnajqr0...@george.home.org>, on 07/23/2002
> at 02:45 PM, Doc <d...@elsewhere.com> said:
>
> > It's amazing how many professionals don't know the difference.
>
> Madison Avenue systematically abused the word to the point where it
> lost its meaning entirely and now has no more semantic content that
> "whiter than white". The original definition was in terms of word
> lengh, price and size. Basically, to be a mini it had to be light
> enough for one person to move it, have a short word size and cost in
> the low thens of thousands (US$). There was also a word "midi" used
> for the 24-bit machines.
Mainframe for me implies separate processors for certain tasks, i.e. a CPU,
an IO processor
(IOM) and a maintenance processor. In a mini computer the CPU performs these
tasks.
That is not a straightforward definition either because one may argue
whether a disk controller
in a mini, say an UDA50, that has its own processor logic is actually a
shrunk IOP.
Size and wheels have no meaning imvho.
Hans
Charles Shannon Hendrix
> dk wrote:
>>
>> I always thought the difference betweem Unix and Linux is that the former was
>> developed by Kernigan and Ritchie while working for Ma Bell and the latter was
>> developed by Linux Torvald as an independent project with the idea of making
>> something that is not monolithic.
>>
> Ditto...except it was Ken Thompson and Dennis Ritchie...I am *not*
> sure that Brian Kernighan contributed to the effort... Of course,
> after it got started, lots of A.T.& T. people contributed utilities.
Linux is monolithic. Not sure where you guys got the idea it wasn't.
From the beginning, Linus wrote the system to be monolithic, and was
quite vocal about his dislike of non-monolithic UNIX-like systems.
You can probably find the now infamouse Torvalds vs Tannenbaum threads
on Google.
Charles Shannon Hendrix
>> This thread has carried on a bit further since Davidson's
>> posting, but these paragraphs here aren't quite true in
>> some sense, or at least deserve some amplification.
>
> Just to point out, that this thread started as a response to
> a troll, who insists that nothing prior to the Unix95 spec
> can be termed Unix. In fact (his claim), all such forms
> are unix-like and not Unix. And as such should not
> be discussed as Unix.
That wouldn't have been the "Rev. Don Kool" would it? I'm picking this up
in a.f.c. and I remember the infamous reverend's penchant for destroying
many useful threads in his never ending compaign to police UNIX(TM).
Pete Fenelon
> Linux is monolithic. Not sure where you guys got the idea it wasn't.
>
Probably 'cos it's got loadable device drivers that then become a
part of a monolithic kernel.
> From the beginning, Linus wrote the system to be monolithic, and was
> quite vocal about his dislike of non-monolithic UNIX-like systems.
Indeed. Looks like ast conducted a lot of very interesting research into
something that, deep down, nobody actually needs or wants - at least
he's come up with some useful ideas in places other than OS design.
pete
--
pe...@fenelon.com "serious sport has nothing to do with fair play" - orwell
mlw
>
> "Floyd Davidson" <fl...@ptialaska.net> wrote in message
> news:87adoho...@barrow.com...
>
> [SNIP]
>
> > For whatever reasons, today a lot of people view virtually any
> > pre-microchip computer as a "mainframe", and it is not uncommon
> > to see claims that Unix was "designed for mainframes" from the
> > start. Recently one Usenet poster claimed, when the limitations
> > of the PDP machines was pointed out, that even if the PDP-7 and
> > PDP-11 were not mainframes, Unix still evolved from work on
> > Multics for the GE-645, and therefore it is "mainframe in
> > origination"! :-)
>
> word mainframe. It seemed to pretty much concurr with what I
> guessed, the word originates from the main structural entity
> that the CPU is physically housed/hung-off (eg : circuitry was
> mounted on "frames")...
>
> So I'd argue that the word mainframe is an abusage in itself
> unless someone can come up with an alternative explaination of
> the origin of the word. :)
Same with "bug" which at one point was an actual insect. The entomology of an
expression is interesting, but it is pointless to argue. The accepted meaning
is the meaning ragardless of the origin.
Brian Inglis
wrote:
>Rupert Pigott wrote:
>>
>> "Floyd Davidson" <fl...@ptialaska.net> wrote in message
>> news:87adoho...@barrow.com...
>> So I'd argue that the word mainframe is an abusage in itself
>> unless someone can come up with an alternative explaination of
>> the origin of the word. :)
>
>Same with "bug" which at one point was an actual insect. The entomology of an
^^^^^^^^^^
Aha! Found one!
>expression is interesting, but it is pointless to argue. The accepted meaning
>is the meaning ragardless of the origin.
--
Brian Inglis
<dark.try-eati...@btinternet.com> wrote:
>"Floyd Davidson" <fl...@ptialaska.net> wrote in message
>news:87adoho...@barrow.com...
>
>[SNIP]
>
>> For whatever reasons, today a lot of people view virtually any
>> pre-microchip computer as a "mainframe", and it is not uncommon
>> to see claims that Unix was "designed for mainframes" from the
>> start. Recently one Usenet poster claimed, when the limitations
>> of the PDP machines was pointed out, that even if the PDP-7 and
>> PDP-11 were not mainframes, Unix still evolved from work on
>> Multics for the GE-645, and therefore it is "mainframe in
>> origination"! :-)
>
>There was a thread a while back discussing the origins of the
>word mainframe. It seemed to pretty much concurr with what I
>guessed, the word originates from the main structural entity
>that the CPU is physically housed/hung-off (eg : circuitry was
>mounted on "frames")...
>
>So I'd argue that the word mainframe is an abusage in itself
>unless someone can come up with an alternative explaination of
>the origin of the word. :)
Earlier discussions on the topic seemed to point to a telco
origin regarding where the control logic resided.
Brian Inglis
Sounds like a WE/AT&T/Lucent/Novell/SCO/OpenGroup trademark
lawyer! Did I miss any of the former trademark holders?
Brian Inglis
<cbbr...@acm.org> wrote:
>In an attempt to throw the authorities off his trail, Brian Inglis <Brian....@SystematicSw.ab.ca> transmitted:
>> I think that, at the time, given memory constraints, writing
>> mainframe OSes (TOS/DOS/MFT/MVT/OS, VM/CP, TOPS-10) in assembler was
>> a good engineering choice, and even more so for mini OSes.
>
>In addition, people actually did have the concept of "quasi-portable
>assembly language" back then: ML/I and STAGE2 were notable as macro
>assemblers where a subset would get ported into a specific processor's
>assembly language, and then represent a bootstrap to allow deploying
>the whole language.
>
>http://members.shaw.ca/parz/ML1.html
>
>I think that part of what has happened is that people have gotten
>sufficiently helpless over the years that they get weak in the knees
>at the very thought of having to deal with assembly language.
Oh god! I remember getting involved in some work involving
STAGE2. Was that in one of William M. Waite's books (red and
white cover from AW? perhaps) porting something starting with a
STAGE2 macro processor written in ForTran? And using that to boot
up a native assembler version of whatever? Not too many Google
references to Waite's work in the 1970s.
Jay Maynard
wrote:
>Both machines were fairly new hardware (although the Honeywell was
>continuing to use some older peripherals), both cost the same,
>both ran CPU benchmarks about the same speed.
>I concluded the Vax was a mainframe.
>The main difference was that the Gcos system normally ran two
>to three times the number of concurrent users.
Yup, the Honeywell was definitely a mainframe.
Christopher Browne
> On 26 Jul 2002 13:54:58 GMT, Christopher Browne
> <cbbr...@acm.org> wrote:
>
>>In an attempt to throw the authorities off his trail, Brian Inglis <Brian....@SystematicSw.ab.ca> transmitted:
>>> I think that, at the time, given memory constraints, writing
>>> mainframe OSes (TOS/DOS/MFT/MVT/OS, VM/CP, TOPS-10) in assembler was
>>> a good engineering choice, and even more so for mini OSes.
>>
>>In addition, people actually did have the concept of "quasi-portable
>>assembly language" back then: ML/I and STAGE2 were notable as macro
>>assemblers where a subset would get ported into a specific processor's
>>assembly language, and then represent a bootstrap to allow deploying
>>the whole language.
>>
>>http://members.shaw.ca/parz/ML1.html
>>
>>I think that part of what has happened is that people have gotten
>>sufficiently helpless over the years that they get weak in the knees
>>at the very thought of having to deal with assembly language.
>
> Oh god! I remember getting involved in some work involving
> STAGE2. Was that in one of William M. Waite's books (red and
> white cover from AW? perhaps) porting something starting with a
> STAGE2 macro processor written in ForTran? And using that to boot
> up a native assembler version of whatever? Not too many Google
> references to Waite's work in the 1970s.
That's probably right.
One minor complaint: People seem to be heading off into reminiscence
instead of observing the bigger point I was trying to make:
People have gotten pretty helpless to the point that the sheer
_mention_ of assembly language scares them silly.
Apparently the whole technology of "macro assemblers" has pretty much
been forgotten by most.
HLA <http://webster.cs.ucr.edu/Page_hla/0_Page_hla.html> is a recent
example that isn't too terribly portable, but which seems to nicely
express the way that better assemblers provided meaningful services,
such as:
- Tracking addresses of things for you; you stick in some labels, and
don't need to remember address numbers...
- Providing reasonably high level control structures, where you use
ALGOL-like control structures (if/then/else, repeat/until,
while/endwhile, for/endfor, foreach/endfor, ...) so that the
assembler generates some of the labels behind your back and you're
not left managing hordes of JMP statements on your own.
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://cbbrowne.com/info/multiplexor.html
When they ship styrofoam, what do they pack it in?
Brian Inglis
<cbbr...@acm.org> wrote:
Maybe we didn't see it as much of an issue? Don't think you'll
find much of that attitude in a.f.c -- perhaps other groups may
have differing viewpoints. It's just another language you
sometimes have to learn to do the job properly. It's always
scared those who are OTL (One True Language) programmers, where
OTL is any language that totally insulates you from knowing
anything about the machine architecture.
>Apparently the whole technology of "macro assemblers" has pretty much
>been forgotten by most.
>
>HLA <http://webster.cs.ucr.edu/Page_hla/0_Page_hla.html> is a recent
>example that isn't too terribly portable, but which seems to nicely
>express the way that better assemblers provided meaningful services,
>such as:
>
>- Tracking addresses of things for you; you stick in some labels, and
> don't need to remember address numbers...
GNU assembler (gas) does not a bad job of hiding the common
architectural features of most processors, providing a PDP-11
like assembler for expressing concepts like registers, constants,
indirection, constants, data areas, and labels, while letting you
use machine specific instructions and features.
I much prefer gas on x86 to any of the x86 assemblers I've used
(MS, Turbo, Intel), probably due to my previous experience on
11s.
If someone took the time to write a set of m4 macros for the
POSIX system calls on Unix, and some Block Structured Macros (see
below) along the C model, you might have yourself a fairly nice,
standard, somewhat portable, macro assembler system. Now tell me
that someone has done just this!
I'm not sure how well any of the gas constructs map onto RISC
architectures: I've rarely had to do even a "cc -S" on Sparc or
RS/6000 box code.
OTOH there's always C available everywhere nowadays: the portable
macro assembler with data structures; and many compilers do seem
to generate code about as good as you could produce without
learning all the instruction whimsies of a specific processor.
Maybe that's why assembler seems to be a very narrow specialty
nowadays: only the OS machine specific kernel and compiler code
generator guys need it for their jobs; and probably some holdouts
in the MF world.
>- Providing reasonably high level control structures, where you use
> ALGOL-like control structures (if/then/else, repeat/until,
> while/endwhile, for/endfor, foreach/endfor, ...) so that the
> assembler generates some of the labels behind your back and you're
> not left managing hordes of JMP statements on your own.
I remember writing Block Structured Macros for Macro-11 (after
hours) upon reading an article about them on IBM MFs. Because
Macro-11 allowed either spaces or commas separating macro args,
it came out pretty readable compared to the MF version, and not
too far off Pascal, which was our pseudocode/design language at
the time for both Assembler and Fortran programming: write it as
pseudo-Pascal comments, then hand transliterate into the target
language.
Toby Thain
The Rev. Kool was recently rehabilitated in my eyes when I found a 1999
posting in which he took the time to carefully answer an ULTRIX question
(identifying ironies is left for the reader):
A reminder that one man's crackpot is another man's savant.
Contemplating installing ULTRIX on a VAXstation 3100 myself, so I might
need his help one day :)
Toby
Robert Uhl <ruhl@4dv.net>
>
> It's always scared those who are OTL (One True Language)
> programmers, where OTL is any language that totally insulates you
> from knowing anything about the machine architecture.
In all fairness, it's quite possible to be a OTL sort when that OTL is
assembler...
I cannot think of a real language which doesn't have some use, but I'm
sure one exists. Heck, even monstrosities such as Intercal serve a
useful purpose: they allow one to exercise one's brain in interesting
ways.
--
Robert Uhl <ru...@4dv.net>
A lady came up to me on the street and pointed at my suede jacket. `You
know a cow was murdered for that jacket?' she sneered.
I replied in a psychotic tone, `I didn't know there were any witnesses.
Now I'll have to kill you too.' --Jake Johansen
Pete Fenelon
> sometimes have to learn to do the job properly. It's always
> scared those who are OTL (One True Language) programmers, where
> OTL is any language that totally insulates you from knowing
> anything about the machine architecture.
The vast majority of OTL programmers (where OTL is C++, Java or VB
for those who've started programming in the last ten years or so)
- *are* scared of machine-level programming, if they've ever been
taught it. I've seen bright graduates who assume that their C++
source is interpreted, for example.... once everything gets folded
up inside IDEs and fancy source-level debuggers, the non-curious
stop wondering what goes on behind the scenes.
> I'm not sure how well any of the gas constructs map onto RISC
> architectures: I've rarely had to do even a "cc -S" on Sparc or
> RS/6000 box code.
I have... :/
The trouble with gas is that you usually need to do one level of
mental indirection to go from the representation it uses to the
manufacturers' standard one. Also, gas is pretty much intended as
something for compilers to use, not humans - hence it's not as powerful
as a "proper" macro assembler!
> OTOH there's always C available everywhere nowadays: the portable
> macro assembler with data structures;
The FORTH zealots claim the same.
> and many compilers do seem
> to generate code about as good as you could produce without
> learning all the instruction whimsies of a specific processor.
Compilers generally generally seem to be able to slightly better code
than humans on RISCs because instruction-scheduling for
them is *hard* :)
> too far off Pascal, which was our pseudocode/design language at
> the time for both Assembler and Fortran programming: write it as
> pseudo-Pascal comments, then hand transliterate into the target
> language.
Apropos of nothing, this reminds of me of a company I once used to be
involved in collaborative projects with. They'd express requirements for
their control systems in Fortran, do a detailed design process, code up
the design and verify that the Fortran that came out of the back end of
that process was the same as the Fortran they started with.... Now I've
heard of V&V but that's just.... odd?!
Chris Hedley
> Contemplating installing ULTRIX on a VAXstation 3100 myself, so I might
> need his help one day :)
I tried this ages ago, and of course I didn't read the installation
manual (well obviously! What do you think I am :) which could've
saved me a lot of aggro as it says that it installs on all VS 3100s
except the one I had (can't remember if it's the M76 or just the
SPX card it didn't like) so I ended up installing NetBSD instead.
That's all pretty academic now, though, since the thing won't boot
because of a duff serial controller. I can't bring myself to get
rid of it though, just on the off-chance it miraculously fixes itself
if I leave it undisturbed long enough...
Chris.
--
"If the world was an orange it would be like much too small, y'know?" Neil, '84
http://cbh.paunix.org My stuff, including genealogy, other things, etc
http://www.paunix.org SDF Public Access UNIX: UNIX accounts and webspace!
jmfb...@aol.com
And the way to detect and eradicate those "bugs" was to use
DDT. One of the reasons I liked working with computer
types is that they had wit.
Karl Kleine
> <cbbr...@acm.org> wrote:
>>In an attempt to throw the authorities off his trail, Brian Inglis <Brian....@SystematicSw.ab.ca> transmitted:
>>> I think that, at the time, given memory constraints, writing
>>> mainframe OSes (TOS/DOS/MFT/MVT/OS, VM/CP, TOPS-10) in assembler was
>>> a good engineering choice, and even more so for mini OSes.
>>
>>In addition, people actually did have the concept of "quasi-portable
>>assembly language" back then: ML/I and STAGE2 were notable as macro
>>assemblers where a subset would get ported into a specific processor's
>>assembly language, and then represent a bootstrap to allow deploying
>>the whole language.
>>
>>http://members.shaw.ca/parz/ML1.html
>>
>>I think that part of what has happened is that people have gotten
>>sufficiently helpless over the years that they get weak in the knees
>>at the very thought of having to deal with assembly language.
> Oh god! I remember getting involved in some work involving
> STAGE2. Was that in one of William M. Waite's books (red and
> white cover from AW? perhaps) porting something starting with a
> STAGE2 macro processor written in ForTran? And using that to boot
> up a native assembler version of whatever? Not too many Google
> references to Waite's work in the 1970s.
I got the STAGE2 stuff from Bill Waite yesterday... He has a kit that
starts with C instead of Fortran, and I will put that up on my history
page together with a pdf'ed manual. The full reference is of course his
book that you mention. Look at
http://www.fh-jena.de/~kleine/history
after the weekend.
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> I think that part of what has happened is that people have gotten
> sufficiently helpless over the years that they get weak in the knees
> at the very thought of having to deal with assembly language.
>
language anymore...and I would still *like* to believe it.
But now I'm starting to think that people will *not* admit
that they can program in assembly language...like a secretary
who will *not* admit she knows how to type...because she is
afraid that she will be put to work typing!!!
So perhaps the new crop of programmers just do *not* want to
program in assembly language...
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
The Ghost In The Machine
<cbbr...@acm.org>
wrote
on 27 Jul 2002 02:09:59 GMT
<ahsvdn$vroho$1...@ID-125932.news.dfncis.de>:
Feh. Assembly language is dead easy if one has the documentation.
The main problem for programmers is keeping track of which register,
memory location, etc. has what values (and perhaps how the subroutines
interrelate, in many cases -- but that's not unique to assembly,
certainly). In some cases, one might have to worry about pipelining
to get the delays right, though -- but that's probably only an issue for
drivers, and maybe not even then (can't depend on a PC having a given PC
clock speed nowadays).
What're they teaching the kids now, how to point and click on the
wizards? :-) Maybe I should release my juggler program as a teaching
aid. :-)
>
> Apparently the whole technology of "macro assemblers" has pretty much
> been forgotten by most.
>
> HLA <http://webster.cs.ucr.edu/Page_hla/0_Page_hla.html> is a recent
> example that isn't too terribly portable, but which seems to nicely
> express the way that better assemblers provided meaningful services,
> such as:
>
> - Tracking addresses of things for you; you stick in some labels, and
> don't need to remember address numbers...
>
> - Providing reasonably high level control structures, where you use
> ALGOL-like control structures (if/then/else, repeat/until,
> while/endwhile, for/endfor, foreach/endfor, ...) so that the
> assembler generates some of the labels behind your back and you're
> not left managing hordes of JMP statements on your own.
An assembler is a tool, nothing more -- and it sounds like some
assemblers actually took their "toolishness" seriously (good for them).
:-) Certainly this reminds me (there I go reminiscing again, but I
promise to be brief :-) ) of VMS's MacroAssembler for VAX, which could
almost look like a high-level language.
Of course, other assemblers are little more than a tiny bit of code
which can keep track of symbolic labels. But it still means the
programmer doesn't have to worry quite as much about where the labels
actually are.
--
#191, ewi...@earthlink.net
It's still legal to go .sigless.
Doc
>
> Mainframe for me implies separate processors for certain tasks, i.e. a CPU,
> an IO processor
> (IOM) and a maintenance processor. In a mini computer the CPU performs these
> tasks.
> That is not a straightforward definition either because one may argue
> whether a disk controller
> in a mini, say an UDA50, that has its own processor logic is actually a
> shrunk IOP.
> Size and wheels have no meaning imvho.
I agree absolutely. I probably should have said "Popular criteria".
^^^^^^^
Doc
Doc
> In alt.folklore.computers Charles Shannon Hendrix <sha...@news.widomaker.com> wrote:
>> Linux is monolithic. Not sure where you guys got the idea it wasn't.
>
> Probably 'cos it's got loadable device drivers that then become a
> part of a monolithic kernel.
I think you two are working from two different definitions of
"monolithic".
My interpretation:
First, there's monolithic vs microkernel architecture, as in Hurd.
In micro-, different runtime blocks operate different functions of the
system, and intercommunicate on fast virtual interfaces, as separate
entities.
In monolithic, one block of code runs the machine. A monolithic kernel
runs as a contiguous logical entity. Loadable modules used by Linux and
some other *nices still get loaded _into_ the running kernel, so it's still
considered monolithic architecture.
Then in the Linux world, monolithic refers to a kernel _file_ which is
compiled with all needed support & functions as a single file. a
non-monolithic kernel is compiled with basic support built into the
kernel image, and [usually] optional support & functions are compiled as
external objects.
Doc
Bob Hauck
<ew...@sirius.athghost7038suus.net> wrote:
> Feh. Assembly language is dead easy if one has the documentation.
It is relatively easy to write code that works. Getting good enough
performance to be faster than C is already hard for modern processors
and rapidly getting more so. Pipelining, out-of-order execution, and
internal parallelism can make things a lot more complicated than it was
back in the good old days.
Really the only places where you see much assembler being written by
hand these days is in very small embedded systems and in DSP work. The
former for the obvious reasons, the latter because DSP's have special
signal processing instructions that don't map well to the common high-
level languages (how do you represent bit-reversed addressing in C?).
> In some cases, one might have to worry about pipelining
> to get the delays right, though
Among other things. For instance, some DSP's have a "delay slot" right
after every branch. You can get work done "for free" if you are clever.
If you are not clever, you put in NOP's and lose performance. Even on
conventional processors you can do clever things if you know how things
like branch prediction work on your CPU, while if you don't you may
inadvertantly do something dumb.
The big problem with assembler is that they are all different and it is
hard to be an expert at more than a handful of them. Every chip has its
own peculiarities that you have to keep in mind. What works well on
chip A might be horrible on chip B and vice versa.
I try to limit myself to writing enough assembler to get the environment
set up for C or C++, and maybe some little bits to do hardware-specific
things.
--
-| Bob Hauck
-| To Whom You Are Speaking
-| http://www.haucks.org/
Christopher Browne
> On Sat, 27 Jul 2002 20:00:30 GMT, The Ghost In The Machine
> <ew...@sirius.athghost7038suus.net> wrote:
>
>> Feh. Assembly language is dead easy if one has the documentation.
>
> It is relatively easy to write code that works. Getting good enough
> performance to be faster than C is already hard for modern
> processors and rapidly getting more so. Pipelining, out-of-order
> execution, and internal parallelism can make things a lot more
> complicated than it was back in the good old days.
>
> Really the only places where you see much assembler being written by
> hand these days is in very small embedded systems and in DSP work.
> The former for the obvious reasons, the latter because DSP's have
> special signal processing instructions that don't map well to the
> common high- level languages (how do you represent bit-reversed
> addressing in C?).
That's probably an argument in favor of using a peephole optimizer on
the code after running it through the macro expansion phase.
After all, out-of-order execution is something likely to be handled at
the assembly language level.
Nothing prevents doing things in a manner that resembles:
#!/bin/sh
for file in $@; do
expanded=/tmp/$file.expanded.$$
optimized=/tmp/$file.optimized.$$
o=`echo $file | cut -d . -f 1`
out="$o.o"
expand_macros < $file > $expanded
optimize_assembler < $expanded > $optimized
generate_object < $optimized > $out
done
Where if there are a bunch of "optimizing" steps, they can be added in
the "optimize_assembler" section...
I'm quite game to not bother writing too much of the stuff. The
unfortunate thing is that "kids, these days" are quite likely to never
have seen _any_ of this stuff.
Knowing a bit of assembler is quite useful in some quite non-assembler
contexts, notably when you need to 'generate code' for something.
Some really conspicuous examples include:
-> Generating PCL to throw at PCL printers;
-> Generating Postscript to throw at Postscript printers (and possibly
at DPS display engines);
-> .dvi (guess?)
A little less obvious might include:
-> X protocol
-> IIOP protocol
As a wild thought, I'd suggest that the flailing around at the
_necessity_ of XML-based representations for everything under the sun
come from people having _zero_ comfort level at "generated binary" of
just about any sort.
--
(concatenate 'string "cbbrowne" "@acm.org")
http://cbbrowne.com/info/unix.html
The English exam was a piece of cake---which was a bit of a surprise,
actually, because I was expecting some questions on a sheet of paper.
Tim Shoppa
> I'm quite game to not bother writing too much of the stuff. The
> unfortunate thing is that "kids, these days" are quite likely to never
> have seen _any_ of this stuff.
What frustrates me is seeing bit-banging done in high-level
languages. I don't like seeing it in C either, but that's a low-level
language (flamebait!) so it's a different case...
> Knowing a bit of assembler is quite useful in some quite non-assembler
> contexts, notably when you need to 'generate code' for something.
> Some really conspicuous examples include:
>
> -> Generating PCL to throw at PCL printers;
> -> Generating Postscript to throw at Postscript printers (and possibly
> at DPS display engines);
I think that knowing multiple languages is the key part to
tasks like this. Whether those languages be C, Perl, Lisp,
Assembly, or Algol doesn't seem to matter much. If a person has
only ever seen C or only has ever seen Visual Basic they really
have a hard time grasping how one program can generate another
program.
Outside of "programming languages" I'm increasingly encountering
personal difficulties with not just people, but entire organizations
where "database" is synonymous with "Oracle". It's like they cannot
envision having data exist or persist outside Oracle.
And, finally, human-language technical writing is in itself an
art form, perfected into a science when cast into a widely used RFC.
After reading so many good RFC's, it's really frustrating to come across
a protocol spec which is either
- Marketing disgused as a spec (too true for so many protocols today)
or
- The .h file used to build a C struct. A struct is not a
protocol specification!
Tim.
Doc
<sha...@news.widomaker.com> wrote:
>
> That wouldn't have been the "Rev. Don Kool" would it? I'm picking this up
> in a.f.c. and I remember the infamous reverend's penchant for destroying
> many useful threads in his never ending compaign to police UNIX(TM).
>
Oh, man! You just *had* to say the name, didn't you?
Some words were best unspoken.
Doc
Ross Simpson
>
> What frustrates me is seeing bit-banging done in high-level
> languages. I don't like seeing it in C either, but that's a
low-level
> language (flamebait!) so it's a different case...
I'm afraid I'm going to have to disagree with that, Tim. Assembly is
the only language I can say for sure that it is at a low-level.
The only reason I disagree with that is because I've seen code
produced from a C compiler which could have been made even smaller if
it was done in Assembly.
Apart from that, I'm not saying that C is a bad language, it just the
sort of language that's not quite low-level or as high as a High-Level
language.
Regards,
Ross.
Dave
> According to Toby Thain <to...@telegraphics.com.au>:
>> Contemplating installing ULTRIX on a VAXstation 3100 myself, so I might
>> need his help one day :)
> I tried this ages ago, and of course I didn't read the installation
> manual (well obviously! What do you think I am :) which could've
> saved me a lot of aggro as it says that it installs on all VS 3100s
> except the one I had (can't remember if it's the M76 or just the
> SPX card it didn't like) so I ended up installing NetBSD instead.
> That's all pretty academic now, though, since the thing won't boot
> because of a duff serial controller. I can't bring myself to get
> rid of it though, just on the off-chance it miraculously fixes itself
> if I leave it undisturbed long enough...
Occasionally I find that this practice of leaving something around to fix
itself actually works. I can recall "fixing" at least five different
computers over ten years this way. I've lost track of other devices that
came back to life this way. I attribute this to a sort of osmosis wherein
osmotic pressure from good bits (from working, but idle equipment stored
nearby) crowd out the rotten ones. Less-often, this works with software
too.
--
David Griffith
dgr...@cs.csubak.edu
Chris Hedley
> Occasionally I find that this practice of leaving something around to fix
> itself actually works. I can recall "fixing" at least five different
> computers over ten years this way. I've lost track of other devices that
> came back to life this way. I attribute this to a sort of osmosis wherein
> osmotic pressure from good bits (from working, but idle equipment stored
> nearby) crowd out the rotten ones. Less-often, this works with software
> too.
There's clearly a lot to be said for the "I'll try it again tomorrow"
approach (or, perhaps, "I'll try it again next year/decade" for
particularly recalcitrent problems)! It's not just applicable in
computing either, I've noticed that car engines also tend to benefit
from the same wisdom.
jmfb...@aol.com
Charles Richmond <rich...@ev1.net> wrote:
>Christopher Browne wrote:
>>
>> [snip...] [snip...] [snip...]
>>
>> I think that part of what has happened is that people have gotten
>> sufficiently helpless over the years that they get weak in the knees
>> at the very thought of having to deal with assembly language.
>>
>I used to believe that people could *not* handle assembly
>language anymore...and I would still *like* to believe it.
>
>But now I'm starting to think that people will *not* admit
>that they can program in assembly language...like a secretary
>who will *not* admit she knows how to type...because she is
>afraid that she will be put to work typing!!!
>
>So perhaps the new crop of programmers just do *not* want to
>program in assembly language...
>
programmer. He boasted that he had a coworker fired because the
guy suggested they do some piece of the game in assembler.
Now, I don't believe him at all w.r.t. the firing bit. I am
concerned about the snobbery.
jmfb...@aol.com
I have a 3x7 card that tells me how to do that programming. I
haven't seen a compiler able to do that.
>The main problem for programmers is keeping track of which register,
>memory location, etc. has what values (and perhaps how the subroutines
>interrelate, in many cases -- but that's not unique to assembly,
>certainly).
It is? I never thought of it being a problem. With an assembly
listing there's only so many places that can smash data. With
a compiler language you don't have any idea what it's doing.
Or am I just showing my uneducated bias again?
> ... In some cases, one might have to worry about pipelining
>to get the delays right, though -- but that's probably only an issue for
>drivers, and maybe not even then (can't depend on a PC having a given PC
>clock speed nowadays).
>
>What're they teaching the kids now, how to point and click on the
>wizards? :-) Maybe I should release my juggler program as a teaching
>aid. :-)
Mutter...I'll never catch me a wizard if I have to do that!
/BAH
<snip>
jmfb...@aol.com
Dave <dgr...@pegasus.cs.csubak.edu> wrote:
>Chris Hedley <c...@ieya.co.remove_this.uk> wrote:
>> According to Toby Thain <to...@telegraphics.com.au>:
>>> Contemplating installing ULTRIX on a VAXstation 3100 myself, so I might
>>> need his help one day :)
>
>> I tried this ages ago, and of course I didn't read the installation
>> manual (well obviously! What do you think I am :) which could've
>> saved me a lot of aggro as it says that it installs on all VS 3100s
>> except the one I had (can't remember if it's the M76 or just the
>> SPX card it didn't like) so I ended up installing NetBSD instead.
>> That's all pretty academic now, though, since the thing won't boot
>> because of a duff serial controller. I can't bring myself to get
>> rid of it though, just on the off-chance it miraculously fixes itself
>> if I leave it undisturbed long enough...
>
>Occasionally I find that this practice of leaving something around to fix
>itself actually works. I can recall "fixing" at least five different
>computers over ten years this way. I've lost track of other devices that
>came back to life this way.
This is not true with the CD-reader I have in this system. If it
is not used periodically, it goes on strike. I didn't use it
for a year and now it's appears to have retired.
> .. I attribute this to a sort of osmosis wherein
>osmotic pressure from good bits (from working, but idle equipment stored
>nearby) crowd out the rotten ones. Less-often, this works with software
>too.
Oh, no. One the days when nothing works, you stop and go home.
When you come in the next day, the damned stuff works just fine
proving, once again, that you must have hallucinated all the
problems.
Brian {Hamilton Kelly}
> Same with "bug" which at one point was an actual insect. The entomology of an
> expression is interesting, but it is pointless to argue. The accepted meaning
> is the meaning ragardless of the origin.
Please confirm that "entomology" in place of "etymology" was deliberate!
--
Brian {Hamilton Kelly} b...@dsl.co.uk
"We have gone from a world of concentrated knowledge and wisdom to one of
distributed ignorance. And we know and understand less while being incr-
easingly capable." Prof. Peter Cochrane, formerly of BT Labs
Rupert Pigott
[SNIP]
> I have a 3x7 card that tells me how to do that programming. I
> haven't seen a compiler able to do that.
You've been using the wrong compilers then. There are plenty
of languages that can be described on a single sheet of A4, and
I have no doubt that 3x7 cards are a possibility too. :)
> >The main problem for programmers is keeping track of which register,
> >memory location, etc. has what values (and perhaps how the subroutines
> >interrelate, in many cases -- but that's not unique to assembly,
> >certainly).
>
> It is? I never thought of it being a problem. With an assembly
> listing there's only so many places that can smash data. With
> a compiler language you don't have any idea what it's doing.
> Or am I just showing my uneducated bias again?
You are. You also just got baited into x-posting the reply to
a LINUX newsgroup. Should be fun. :)
Cheers,
Rupert
GreyCloud
Hehehe... looks like I share your same viewpoint on many
peoples claims. :-)
I went thru the school of hard knocks and screwed a few
times, but no worse for the wear.
J. Clarke
Talk about snobbery, I used to know a guy who wrote all his programs in
machine code--he claimed that Assembler didn't let him get close enough
to the machine. Of course his productivity was a close approximation of
zero, so he had a heck of a lot of trouble holding a job . . .
>
> /BAH
>
> Subtract a hundred and four for e-mail.
>
--
--
--John
Reply to jclarke at ae tee tee global dot net
(used to be jclarke at eye bee em dot net)
Edgar Allen
I remember reading an article in Dr. Dobbs where the author
explained about having written an assembler for the Motorola 68000
which used a subset of C.
He could write the initial code in C and use full debug facilities
and then hand it over to the assembler to move to the target
machine.
Turns out that integer operations on the 68000 came out as one or
two instructions. Which made me question why move at all since
the assembler could not do much better.
It also taught me to see C as little higher level than assembly.
--
Microsoft is trying to add to the list of biggest lies of all time:
"We are just like Linux but with different terminology."
Besides it not being true, they cost more for poorer performance.
Russ
Recently I had to write some code in machine language. I was trying to use a
Borland compiler to generate some code for an x86 target. The compiler
didn't support the assembler commands for doing some of the mode/page
switching. So I had to put in some dummy asm{...} instructions. Then go
back to the machine code output file and edit it to insert the required
instructions. Sheesh.
--
Russ Lyttle - Not powered by ActiveX
Please visit <http://home.earthlink.net> for OBD-II
information and links.
Ross Simpson
"Edgar Allen" <eal...@allenhome.kc.rr.com> wrote in message...
> Then that was a lousy C compiler and possibly a crappy CPU.
> I remember reading an article in Dr. Dobbs where the author
> explained about having written an assembler for the Motorola
68000
> which used a subset of C.
If I said it was on a Mac you wouldn't believe me. Fortunately it was
on an IBM compatable. But I don't see the relevance as to why a crappy
CPU would effect the program produced. The C compiler I'm talking
about is actually Borland's C!
But I also seen other C compilers (such as Small C & Digital
Research's C compiler) which compile the program differenty. Instead
of creating a program they compile the code into it's assembly form
(which can be compiled into a program through an assembler).
But I've seen other programs such as Emulators which run slower
compared to if it was done in Assembly. This is another indication
that the C compiler it was done in has produced a larger program which
requires a faster computer.
Regards,
Ross.
Dowe Keller
> But I also seen other C compilers (such as Small C & Digital
> Research's C compiler) which compile the program differenty. Instead
> of creating a program they compile the code into it's assembly form
> (which can be compiled into a program through an assembler).
IIRC, gcc does this. It compiles the code into assembly and runs it
through as.
--
do...@sierratel.com <http://www.sierratel.com/dowe>
"World domination. Fast"
(By Linus Torvalds)
Charles Richmond
>
> [snip...] [nsip...] [snip...]
>
> Recently I had to write some code in machine language. I was trying to use a
> Borland compiler to generate some code for an x86 target. The compiler
> didn't support the assembler commands for doing some of the mode/page
> switching. So I had to put in some dummy asm{...} instructions. Then go
> back to the machine code output file and edit it to insert the required
> instructions. Sheesh.
>
you wrote!!! Even with voluminous comments, he/she will have
a devil of a time figuring out what you did...
jmfb...@aol.com
>jmfb...@aol.com wrote:
>>
>> In article <3D42F11B...@ev1.net>,
>> Charles Richmond <rich...@ev1.net> wrote:
>> >Christopher Browne wrote:
>> >>
>> >> [snip...] [snip...] [snip...]
>> >>
>> >> I think that part of what has happened is that people have gotten
>> >> sufficiently helpless over the years that they get weak in the knees
>> >> at the very thought of having to deal with assembly language.
>> >>
>> >I used to believe that people could *not* handle assembly
>> >language anymore...and I would still *like* to believe it.
>> >
>> >But now I'm starting to think that people will *not* admit
>> >that they can program in assembly language...like a secretary
>> >who will *not* admit she knows how to type...because she is
>> >afraid that she will be put to work typing!!!
>> >
>> >So perhaps the new crop of programmers just do *not* want to
>> >program in assembly language...
>> >
>> I just chastised a kiddie who claimed he was a super-duper game
>> programmer. He boasted that he had a coworker fired because the
>> guy suggested they do some piece of the game in assembler.
>> Now, I don't believe him at all w.r.t. the firing bit. I am
>> concerned about the snobbery.
>Hehehe... looks like I share your same viewpoint on many
>peoples claims. :-)
>I went thru the school of hard knocks and screwed a few
>times, but no worse for the wear.
I don't know any other way for a newbie to figure out how
a machine really works. ASCII is for people, not machines.
jmfb...@aol.com
jmfb...@aol.com
>Recently I had to write some code in machine language. I was trying to use
a
>Borland compiler to generate some code for an x86 target. The compiler
>didn't support the assembler commands for doing some of the mode/page
>switching. So I had to put in some dummy asm{...} instructions. Then go
>back to the machine code output file and edit it to insert the required
>instructions. Sheesh.
<grin> That's why JMF believed that "Have EDDT, will travel."
jmfb...@aol.com
"Rupert Pigott" <dark.try-eati...@btinternet.com> wrote:
><jmfb...@aol.com> wrote in message news:ai0ige$2ab$2...@bob.news.rcn.net...
>[SNIP]
>> I have a 3x7 card that tells me how to do that programming. I
>> haven't seen a compiler able to do that.
>
>You've been using the wrong compilers then. There are plenty
>of languages that can be described on a single sheet of A4, and
>I have no doubt that 3x7 cards are a possibility too. :)
I don't believe that. The print does have to be readable.
>
>> >The main problem for programmers is keeping track of which register,
>> >memory location, etc. has what values (and perhaps how the subroutines
>> >interrelate, in many cases -- but that's not unique to assembly,
>> >certainly).
>>
>> It is? I never thought of it being a problem. With an assembly
>> listing there's only so many places that can smash data. With
>> a compiler language you don't have any idea what it's doing.
>> Or am I just showing my uneducated bias again?
>
>You are. You also just got baited into x-posting the reply to
>a LINUX newsgroup. Should be fun. :)
<shrug> I didn't know that was a "bad" thing. We had
to deal with all kinds in my neck of the biz. LINUXers
haven't struck me as problems.
Sven Mascheck
> The Rev. Kool was recently rehabilitated in my eyes when I found a 1999
(How can a poster trolling currently, ever get rehabilitated by a posting
from the past?)
> posting in which he took the time to carefully answer an ULTRIX question
> [...] <36F5238C...@home.com> [...] Contemplating installing
> ULTRIX on a VAXstation 3100 myself
(...except that he wrote about Digital UNIX aka OSF/1 -- and not Ultrix.)
In comp.unix.ultrix, <aenced$8dob8$1...@ID-115747.news.dfncis.de>,
somebody recently wrote about trying to install an Ultrix CD on
the VAX emulator in "simh".
Did anybody here succeed with an "image" from TUHS (if this is
possible at all)?
Sven
Alan T. Bowler
> But I also seen other C compilers (such as Small C & Digital
> Research's C compiler) which compile the program differenty. Instead
> of creating a program they compile the code into it's assembly form
> (which can be compiled into a program through an assembler).
generally, the output of the assembler was an object deck
and you needed to run this through a linker to produce an
executable program.
The technique of using the assembler as the object deck writer
for a compiler is quite old (7090 era at least). It can make it
a bit easier to get a compiler up and running quickly, because
emitting text is a bit easier than the specialized format needed
for the object deck. Also you don't need to write special code
(disassembler, object deck listers, to seem what code seqeunces
the compiler is actually emitting.) However, in the long run it
tends to be a losing proposition. Limitations in the assembler can
be reflected back as language restrictions. Worse, the assembler
gets to be viewed merely as the object deck writer for the
compilers, and so the emphasis in its design gets to be on
doing that function quickly, and features that are usually
assumed by assembler programmers (good macro processors etc.),
get omitted. Coding in assembler is much easier if you can
get the assembler to look asfer details like calculations
for stack offsets, frame sizes, and stack bumps.
Supplying a good object deck generation library that can be used
by both the compilers and the assmbler is better in the long run.
Rupert Pigott
> In article <ai188m$i9c$1...@paris.btinternet.com>,
> "Rupert Pigott" <dark.try-eati...@btinternet.com> wrote:
> ><jmfb...@aol.com> wrote in message
news:ai0ige$2ab$2...@bob.news.rcn.net...
> >[SNIP]
> >> I have a 3x7 card that tells me how to do that programming. I
> >> haven't seen a compiler able to do that.
> >
> >You've been using the wrong compilers then. There are plenty
> >of languages that can be described on a single sheet of A4, and
> >I have no doubt that 3x7 cards are a possibility too. :)
>
> I don't believe that. The print does have to be readable.
C, Prolog, Lisp, Pop-11. Those are just the ones I've seen
single side A4 summaries of. I suspect that there are plenty
of others that could have A4 summaries written. :P
I was thinking the same about those 3x7 cards describing
assembler. Can't think of many processors that you could get
enough info onto a legible 3x7 to define their architecture.
I think that with most you'd have to lose a lot of the more
esoteric instructions.
> >> >The main problem for programmers is keeping track of which register,
> >> >memory location, etc. has what values (and perhaps how the subroutines
> >> >interrelate, in many cases -- but that's not unique to assembly,
> >> >certainly).
> >>
> >> It is? I never thought of it being a problem. With an assembly
> >> listing there's only so many places that can smash data. With
> >> a compiler language you don't have any idea what it's doing.
> >> Or am I just showing my uneducated bias again?
> >
> >You are. You also just got baited into x-posting the reply to
> >a LINUX newsgroup. Should be fun. :)
>
> <shrug> I didn't know that was a "bad" thing. We had
> to deal with all kinds in my neck of the biz. LINUXers
> haven't struck me as problems.
No, but if we're unlucky alt.folklore will get trashed by
LINUX 'advocates'.
Cheers,
Rupert
The Ghost In The Machine
<jmfb...@aol.com>
wrote
on Sun, 28 Jul 02 09:48:44 GMT
<ai0ige$2ab$2...@bob.news.rcn.net>:
Agreed; while C is fairly simple, I'm not sure the language would
fit on a 3x7 card unless the font was teeny tiny -- never mind the
Portable Library. :-)
>
>>The main problem for programmers is keeping track of which register,
>>memory location, etc. has what values (and perhaps how the subroutines
>>interrelate, in many cases -- but that's not unique to assembly,
>>certainly).
>
> It is? I never thought of it being a problem. With an assembly
> listing there's only so many places that can smash data. With
> a compiler language you don't have any idea what it's doing.
> Or am I just showing my uneducated bias again?
No, you're more or less right, actually. Why people are so skeered of
assembly language isn't horribly clear, although it may be because
they're skeered of details; one does have to keep track of where
one's data is as it moves from memory to register to register back to
memory. Of course, that's true in C also.
>
>
>> ... In some cases, one might have to worry about pipelining
>>to get the delays right, though -- but that's probably only an issue for
>>drivers, and maybe not even then (can't depend on a PC having a given PC
>>clock speed nowadays).
>>
>>What're they teaching the kids now, how to point and click on the
>>wizards? :-) Maybe I should release my juggler program as a teaching
>>aid. :-)
>
> Mutter...I'll never catch me a wizard if I have to do that!
You wouldn't want to catch these wizards; they're stupid. :-)
One might be better off trying to capture, say, Mickey Mouse in
_The Sorceror's Apprentice_ or some such. At least he had
some wizardry. (And the music wasn't bad, either. :-) )
>
> /BAH
> <snip>
>
> /BAH
>
> Subtract a hundred and four for e-mail.
--
#191, ewi...@earthlink.net
It's still legal to go .sigless.
Dowe Keller
> C, Prolog, Lisp, Pop-11. Those are just the ones I've seen
> single side A4 summaries of. I suspect that there are plenty
> of others that could have A4 summaries written. :P
What kind of lisp? Scheme I would believe. Common Lisp, on the other
hand, is almost as hairy as Perl (That should get the lisp weenies
whining :).
--
do...@sierratel.com <http://www.sierratel.com/dowe>
"Whip me. Beat me. Make me maintain AIX."
(By Stephan Zielinski)
Steve O'Hara-Smith
Tim Shoppa <sho...@trailing-edge.com> wrote:
TS> Christopher Browne wrote:
TS> in C either, but that's a low-level
TS> language (flamebait!) so it's a different case...
I think that one has been thoroughly oxidised by now and is no longer
flammable :)
TS> Outside of "programming languages" I'm increasingly encountering
TS> personal difficulties with not just people, but entire organizations
TS> where "database" is synonymous with "Oracle". It's like they cannot
TS> envision having data exist or persist outside Oracle.
These people react in real horror if you let them know that files
can be used to hold data :)
--
C:>WIN | Directable Mirrors
The computer obeys and wins. |A Better Way To Focus The Sun
You lose and Bill collects. | licenses available - see:
| http://www.sohara.org/
jmfb...@aol.com
"Rupert Pigott" <dark.try-eati...@btinternet.com> wrote:
><jmfb...@aol.com> wrote in message news:ai397r$sat$1...@bob.news.rcn.net...
>> In article <ai188m$i9c$1...@paris.btinternet.com>,
>> "Rupert Pigott" <dark.try-eati...@btinternet.com> wrote:
>> ><jmfb...@aol.com> wrote in message
>news:ai0ige$2ab$2...@bob.news.rcn.net...
>> >[SNIP]
>> >> I have a 3x7 card that tells me how to do that programming. I
>> >> haven't seen a compiler able to do that.
>> >
>> >You've been using the wrong compilers then. There are plenty
>> >of languages that can be described on a single sheet of A4, and
>> >I have no doubt that 3x7 cards are a possibility too. :)
>>
>> I don't believe that. The print does have to be readable.
>
>C, Prolog, Lisp, Pop-11. Those are just the ones I've seen
>single side A4 summaries of. I suspect that there are plenty
>of others that could have A4 summaries written. :P
A complete list of all constructs can be fit on a card? I don't
think so.
>
>I was thinking the same about those 3x7 cards describing
>assembler. Can't think of many processors that you could get
>enough info onto a legible 3x7 to define their architecture.
>I think that with most you'd have to lose a lot of the more
>esoteric instructions.
One of the things I was playing^Wwrestling with Billyboystuff
was to try to bi(t)gitize our (PDP-10) System Reference Card.
The instruction architecture was so elegant that the mnemonics
were organized such that each character position branched down
a logical tree. And the branches were rather parallel w.r.t
the mnemonics. If you "knew" one instruction construct, you
could pretty much guess the rest of them.
>
>> >> >The main problem for programmers is keeping track of which register,
>> >> >memory location, etc. has what values (and perhaps how the
subroutines
>> >> >interrelate, in many cases -- but that's not unique to assembly,
>> >> >certainly).
>> >>
>> >> It is? I never thought of it being a problem. With an assembly
>> >> listing there's only so many places that can smash data. With
>> >> a compiler language you don't have any idea what it's doing.
>> >> Or am I just showing my uneducated bias again?
>> >
>> >You are. You also just got baited into x-posting the reply to
>> >a LINUX newsgroup. Should be fun. :)
>>
>> <shrug> I didn't know that was a "bad" thing. We had
>> to deal with all kinds in my neck of the biz. LINUXers
>> haven't struck me as problems.
>
>No, but if we're unlucky alt.folklore will get trashed by
>LINUX 'advocates'.
<shrug> TOPS-10ers had to do that every day.
jmfb...@aol.com
Library? That's one of the first steps when you have your
assembler. Or don't people do that anymore? Write common
routines callable by subsequent development so that the
same functionality doesn't have to be debugged <yawn> yet
again. People do program like this just naturally...or
am I being biased and naive again?
>>>The main problem for programmers is keeping track of which register,
>>>memory location, etc. has what values (and perhaps how the subroutines
>>>interrelate, in many cases -- but that's not unique to assembly,
>>>certainly).
>>
>> It is? I never thought of it being a problem. With an assembly
>> listing there's only so many places that can smash data. With
>> a compiler language you don't have any idea what it's doing.
>> Or am I just showing my uneducated bias again?
>
>No, you're more or less right, actually.
<grin> Well, I'll pick the 'more right' option.
> .. Why people are so skeered of
>assembly language isn't horribly clear, although it may be because
>they're skeered of details; one does have to keep track of where
>one's data is as it moves from memory to register to register back to
>memory. Of course, that's true in C also.
But that's easy. In a compiler, one sorta drops them into
a bin and hopes it stays static while pawing through the
data looking for it, especially in the cases where the
execution crosses program boundaries. I hated writing
CALLs in FORTRAN because I never knew when I was going
to get clobbered. I like all of the cards laid out on
the table, face up; life has enough surprises without
my inventing more of them :-).
>>> ... In some cases, one might have to worry about pipelining
>>>to get the delays right, though -- but that's probably only an issue for
>>>drivers, and maybe not even then (can't depend on a PC having a given PC
>>>clock speed nowadays).
>>>
>>>What're they teaching the kids now, how to point and click on the
>>>wizards? :-) Maybe I should release my juggler program as a teaching
>>>aid. :-)
>>
>> Mutter...I'll never catch me a wizard if I have to do that!
>
>You wouldn't want to catch these wizards; they're stupid. :-)
>One might be better off trying to capture, say, Mickey Mouse in
>_The Sorceror's Apprentice_ or some such. At least he had
>some wizardry. (And the music wasn't bad, either. :-) )
A lot my friends toked up just before they'ld go see that movie.
Toby Thain
> Toby Thain wrote:
>
>
>>The Rev. Kool was recently rehabilitated in my eyes when I found a 1999
>
>
> (How can a poster trolling currently, ever get rehabilitated by a posting
> from the past?)
Since his reputation seems generally poor in these parts I felt it was
only fair to point out a remarkably helpful post :) - one good troll
deserves another, as I always say.
>
>
>>posting in which he took the time to carefully answer an ULTRIX question
>>[...] <36F5238C...@home.com> [...] Contemplating installing
>>ULTRIX on a VAXstation 3100 myself
>
>
> (...except that he wrote about Digital UNIX aka OSF/1 -- and not Ultrix.)
You are quite right. Apologies for the error!
>
>
> In comp.unix.ultrix, <aenced$8dob8$1...@ID-115747.news.dfncis.de>,
> somebody recently wrote about trying to install an Ultrix CD on
> the VAX emulator in "simh".
>
> Did anybody here succeed with an "image" from TUHS (if this is
> possible at all)?
My problem seemed to be that the v.4.3/4.5 CD installation script didn't
find devices it liked (wants RZ SCSI driver I think?) I'll have to look
up that posting you mention - they must have been attempting with an
earlier version of ULTRIX that can use the extant simh/VAX drivers?
Toby
>
> Sven