Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site hhb.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!drutx!houxe!hogpc!houti!ariel!vax135!floyd!cmcl2!philabs!hhb!bob
From: bob@hhb.UUCP
Newsgroups: net.unix-wizards,net.arch
Subject: Re: Re: Re: Pyramid architectural restraints
Message-ID: <150@hhb.UUCP>
Date: Tue, 1-May-84 23:10:39 EDT
Article-I.D.: hhb.150
Posted: Tue May  1 23:10:39 1984
Date-Received: Fri, 4-May-84 05:07:03 EDT
Organization: HHB-Softron, Mahwah, NJ
Lines: 80



Its time for a response.

When I posed my question regarding the problem we were having with the
pyramid system, I really wasn't looking for technical solutions to the
problem, and I wasn't looking for replies telling me that we had just
plain written the code wrong (PERIOD). (Implied in that statement was
that we must be bumbling fools who shouldn't be allowed behind the
wheel of a C Compiler), all I was looking for was whether this type of
architecture would be dominant in the future, so that if it was, we can
schedule a fix for it in the future.

Now for a credibility speech.

Me and my company have been involved with UN*X for quite a while.  We
have done two native portations to a word addressed computer.  One of
them UN*X v7m, and the other being System III.  We have also done 3 C
compiler code generators, 2 for word addressed machines and the other
for the hp 1000 series machines (2 registers, no byte addressing!).  We
also did the XENIX adaptation for the IBM Instruments CS9000 computer.
I feel we are quite competent at what we do, and have an excellent
knowledge of compilers, and machine architectures.

Now for a plea.

Please - No more solutions to our problem, like -- write subroutines to
fetch the bytes individually, use macros, trap the fault in the kernel
and fix it there........ and on and on and on...  We've already thought
of the different ways to fix it, and feel, as stated, that to do it
CORRECTLY would take 10 man months.

Now for some exhaust from my after-burners ----->>>>>>>>>>********

Now let me flame at the folkz who felt compelled to tell me that we had
written the code completely wrong.  These responses we just typical
(and as I had expected) of UN*X snob types with little understanding of
what it takes to develop major software systems.  With attitudes like
that we ought to just throw most of UN*X out the window.  Do you have
any idea how much effort we spent making the UN*X utilities work on a
machine that did not have character pointers the same size as all other
pointers ?  (This was for the word addressed machine I had previously
mentioned).  It was months, and an extremely tedious job.  So obviously
they wrote UN*X wrong PERIOD.

No, you're right, it was written wrong, from a purely technical,
non-realistic viewpoint.  Maybe those who write code perfectly and
think of ALL considerations before they code, do not have deadlines,
schedules, and real world problems to address.  I'm also sure that they
have plenty of time to conduct seminars for all the new people they
hire, espousing to them the perfect way to write C code.  But then
again, maybe the most ambitious system they have developed is
comparable to a `grep' program.  Or else maybe they have large
contracts from the government.  (I worked for a defense contractor
once....)

Did we make assumptions about the architecture of the machine we would
run on ?  Yup, for instance, we'll never run on an 8086 microprocessor
because we assume we have a linear address space greater than 64k.
(Unless someone comes out with a true large model compiler for it). And
won't lose much from that decision.  It boils down to speed/space vs.
generality and we chose a compromise position. It bit us with the RISC
machines, but unless they are the wave of the future (which was the
original question i was posing) we won't disrupt our development cycle
for them.

Anyways, what the flamers ignored was that we now run on 12 different
systems, and will run on many more to come, without mods to our
system.  So I fail to see that we wrote it completely wrong.  And I
admit, it won't port to a 67 bit flammigabar machine, but it sure seems
to be a useful product in the market it enjoys.  So how about coming
out of your ivory towers and just try to put things in perspective.



========================================================== Be

Company:        HHB-Softron UUCP address:
{decvax,allegra}!philabs!hhb!bob