Groups | Search | Server Info | Login | Register

Groups > comp.sys.prime > #158

Re: Georgia Tech Software Tools for Primos

Show all headers | View raw

In article <1b811bb7-a9e0-4efb-9e9c-a493e97833a9@b8g2000yqh.googlegroups.com>,
	Daiyu Hurst <daiyu.hurst@gmail.com> writes:
> On Dec 14, 8:07 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
>> In article <badcca16-ee32-499e-b50e-0d1e5f1d7...@j4g2000yqh.googlegroups.com>,
>>         Daiyu Hurst <daiyu.hu...@gmail.com> writes:
>> > On Dec 13, 8:57 pm, d...@ihatespam.msu.edu (Dennis Boone) wrote:
>> >>  > Folks, does this look like the Holy Grail of which we speak? I got
>> >>  > this from a member of my Control Data group; it appears to be the
>> >>  > portable distribution, un-ported.
>>
>> >> I'm pretty sure GATech made some enhancements to integrate the
>> >> basic STOS with PRIMOS.  Here's the User Guide for the GATech
>> >> version:
>>
>> >>http://yagi.h-net.msu.edu/prime_manuals/GIT-ICS-85-08_Software_Tools_...
>>
>> >> De
>> > I confess...
>> > I'm a computer programmer at heart. Jim's sig line (or the one he
>> > used to use) expresses my feelings very succinctly:
>> > Software First! (Software Lasts!)
>> > Pick the software you want. Then find the hardware that best runs it.
>> > If the hardware doesn't exist, design it and build it.
>>
>> With the single exception of The UCSD-Pascal Microengine, name one case
>> where this was what happened.  Hardware invariably come first.  Probably
>> because it's a lot easier to customize software to fit on the hardware
>> than the other way around.
> The Intel iAPX432 CPU chipset was designed as a platform for
> capability-based
> operating systems and languages like ADA.
> The MIT-CADR, LMI-CADR, LM-2, et. al, and the follow-on Symbolics
> LISP Machine were designed to run LISP, as were some machines from
> TI and Xerox.
> Rockwell, Patriot Scientific, and of course, Sun, have designed and
> sold JAVA CPUs.
> Mushroom, J-Machine, and SOAR (Smalltalk On A RISC) were designed to
> run Smalltalk.   <3
> The University of Illinois Zephyr machines were 4-CPU clones of the
> CDC 6400, done in ECL, but lacking peripheral processors, and were
> designed specifically to run PLATO.
> The Burroughs B5000 was designed to run Algol-60.
> Multics was designed for a machine that didn't yet exist. On the
> GE645,
> the rings of protection had to emulated. The target for Multics was
> the
> 645FO (Follow-On), which sadly never got built. Instead Honeywell
> built
> the 6000 series machines, some of which contained the minimal features
> Multics needed to run.
> And of course, Prime took their early Honeywell-based CPUs and added
> to
> them the features needed to run PRIMOS IV, which was always intended
> to
> be Prime's vision of a second-generation Multics.
> And there are countless re-implementations of machine architectures
> that
> have been created specifically to take advantage of an existing base
> of
> software. And I'm not referring to more modern machine designs done
> by
> the company that did the originals. I'm thinking even of hobbyists who
> have done their own FPGA implementations of the mainframe
> architectures
> they loved.
> No, I'll say it again, a different way. Hardware first is the cart
> leading
> the horse. Software first is the horse leading the cart, as it should
> be.

OK, I see where you are going but being designed with feature to
support a language or concept is not the same thing as writing
the OS and then building a machine to run it.  i did find the
comment avout Javacode hardware interesting.  I will need to
research that a bit (out of curiosity).  Especially being as SUN
was always totally against making a Java compiler that generated
code that was native to a processor.  The Javacode cpu would be
very impractical as bytecode seems to be constantly in flux.  It's
really hard to hit a moving target.  :-)

>> > So I totally fail to comprehend the value of STVOS/Prime, in a way
>> > that I don't fail to comprehend Primix: Primix was a product, it
>> > was meant to make money.
>>
>> Having worked with PRIMIX a lot from the very beginning (My printed manuals
>> are xeroxs of Primes development pages!) I can tell you it was a totally
>> worthless product.  The primary reason for things like PRIMIX and EUNICE
>> were to open up the world of Unix freeware (yes, we had freeware long before
>> the Stallman rant) to other OSes.  It was all about a common API accross
>> multiple platforms.  Long after STVOS was abandoned and lost all the work
>> was re-done in the form of POSIX.
> I get this. But wouldn't you want to choose the platform for all that
> freeware
> that *most readily* lends itself to exploiting it? But then again, if
> the only
> tool you have is a hammer, pretty soon everything begins to look like
> a nail.

Unless you see a world with only one type of system, this variety is
unavoidable.  People will develop for the machine they are working on.
If the software is generally usable other people will want to see it
on their system as well.

> So if a PRIME is all you got, I guess you have to make do. But, I
> don't think
> very many people are in that position today.
> Freeware sourcecode today is not easy to port, due to complex
> dependencies on
> other software, and incomprehensible build automation systems. First

That has nothing to do with the systems they run on or the API.  that
has to do with lack of coordination of the developers.  But given a
program, if it uses an API common among many systems the program can
be ported.  If there is no common API then porting becomes difficult
if not impossible.  Try porting anything to VMS that needs fork().
Or, better still, try porting anything to a Prime that assumes the
values of ASCII characters falls between 0 and 127 (and lot's of
unix software does!!)

> came a
> few tools to make building easier. Then tools to make building the
> building
> tools easier. Work turned to meta-work to meta^meta-work.
> Most of the software I carried to the Prime from the Control Data
> machines
> I'd worked on previously, was easier to port (from a 60-bit word
> machine to
> a 32-bit word machine) than it is today to port a program that builds
> and
> runs fine on an x86 box running Linux, to an x86 box running Darwin.

I don't see why that wold be so hard. Both are just different dialects
of the same OS.  A more intersting problem is going to be porting a
lot of the existing software from 32bit intel to 64bit intel.  But
even that is really the fault of poor development control.  (think:
pointer converted to integer without a cast)

> Someone started a port of gcc to prime ages ago, but even if they ever
> finished it, I think it was gcc 1.x, so I doubt you could get much
> modern freeware ported to it with ease.

Based on personal experience, the biggest problem with porting common
unix software to Primos was the ASCII problem.  It breaks most parsers
which assume values between 0 and 127.  And then we have the NULL issue.
What do you think the numeric value of NULL under Prime C was?  :-)
Hint: it certainly wasn't 0.  How many programs do you think that breaks?

> Now, as to APIs.... a universal API was the long-sought Holy Grail of
> programming. Guess what? We finally got it. It's called the World Wide
> Web.

Sorry, that is hardly an API.  I work with a lot of systems that have no
and will never have access to the "World Wide Web" (whatever that is).
Having an API does not mean running Java off the INTERNET.

> The web even comprises a living descendant to a segmented virtual
> memory,
> in that each web page link is a symbolic address into a huge virtual
> space
> (thanks to PJ Denning for pointing that out).
>> See above.  it was all about a common API and with the advent of POSIX
>> it became even more important, especially if you wanted to sell products
>> to the government.
> I was taught early on as a programmer, to isolate platform-specific
> details
> of application programs into separately-coded modules, to make porting
> the
> application easier. 

Which usually works except when the developer doesn't think anyone
else is ever going to be interested in his program.

>                      I was horrified the first time I saw a BASIC
> program on
> the PC that "jumped" into the BIOS ROM to accomplish something.

Hindsight is always 20/20.  I too have seen this done often, usually as
a means of saving memory which was, in those days, very precious. (My
first mchine supporting BASIC had 4K of RAM.)

>> Except that STVOS was never really an OS.  It's an API.  Of course, there
>> was a real, native Unix for Primes but after backing all the work in the
>> end Prime refused to let the developers release it apparently to protect
>> the market for their extremely inferior PRIMIX product.
> Again, I don't see the point. PRIMOS had its own API. As I come back
> to
> look at it in detail after a long absence, I'm amazed at how it
> evolved.

Yes, it did.  One that it did not share with any other system making
porting software to/from Primos extremely difficult, if not impossible.
Sadly, Prime lived in a vacuum thinking it was the only system in the
industry.  It paid the price. 

> In most cases, different APIs provide equivalent ways to do things, so
> if
> you isolate the platform-specific details, you only have to change
> them
> in one place. 

If you develop to a common API you don't have to change them at all.

>                The sole exception to this seems to be how so many *nix
> platforms lack a way to check for a keypress without echoing it, 

Name them.  I have never seen such a system and I have been doing Unix
for 30 years.

>                                                                   then
> to read the key if it was pressed, and act on it accordingly. When I
> looked into this recently, I found many people asking the same
> question,
> how to do it, and most of the *nix world just said "why on earth do
> you
> want to do that, are you writing a password entry routine, if so, call
> <xxx> and you're done."

You talk to some very strange unix people.  I can think of at least two
ways to do this right off the top of my head.

> I suppose these folks had never written machine emulators that need to
> interact with host hardware transparently, in order to let the
> emulated
> machine's software treat it accordingly.

Sorry, I can't even begin to understand what this means.

>> Nothing wrong with a rant.  Especially if it brings out the explanation
>> for why something was actually done.  Reading Debbie Scherrer's original
>> paper would go a long way towards understanding the goals of the project.
> I did read it, and I get it, I just disagree with the premise.
> The kind of universal API proposed, I find of limited or no value.
> But I think it's nonetheless important to find and preserve this
> software.

Well, I guess the people who reinvented the wqheel to give us POSIX
didn't agree with you.  :-)

> How else can we learn from our mistakes?

Sadly, at least in this industry, people seldom do.  They just go back
and re-invent the wheel with all the same mistakes.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

Back to comp.sys.prime | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Georgia Tech Software Tools for Primos Edward Feustel <efeustel@hughes.net> - 2012-11-30 09:47 -0500
  Re: Georgia Tech Software Tools for Primos Al Kossow <aek@bitsavers.org> - 2012-11-30 09:28 -0800
    Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2012-11-30 22:11 -0800
      Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2012-12-02 10:54 -0800
        Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2012-12-13 15:01 -0800
          Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2012-12-13 15:03 -0800
          Re: Georgia Tech Software Tools for Primos billg999@cs.uofs.edu (Bill Gunshannon) - 2012-12-13 23:14 +0000
            Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2012-12-13 17:19 -0800
          Re: Georgia Tech Software Tools for Primos Al Kossow <aek@bitsavers.org> - 2012-12-13 16:11 -0800
          Re: Georgia Tech Software Tools for Primos drb@ihatespam.msu.edu (Dennis Boone) - 2012-12-13 19:57 -0600
            Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2012-12-13 20:55 -0800
              Re: Georgia Tech Software Tools for Primos billg999@cs.uofs.edu (Bill Gunshannon) - 2012-12-14 13:07 +0000
                Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2012-12-14 08:02 -0800
                Re: Georgia Tech Software Tools for Primos billg999@cs.uofs.edu (Bill Gunshannon) - 2012-12-14 17:11 +0000
                Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2012-12-14 17:41 -0800
                Re: Georgia Tech Software Tools for Primos billg999@cs.uofs.edu (Bill Gunshannon) - 2012-12-15 02:24 +0000
                Re: Georgia Tech Software Tools for Primos drb@ihatespam.msu.edu (Dennis Boone) - 2012-12-15 10:58 -0600
                Re: Georgia Tech Software Tools for Primos drb@ihatespam.msu.edu (Dennis Boone) - 2012-12-15 10:51 -0600
                Re: Georgia Tech Software Tools for Primos matt weber <mattheww50@verizon.net> - 2012-12-16 14:28 -0500
                Re: Georgia Tech Software Tools for Primos Andreas Eder <andreas_eder@gmx.net> - 2012-12-14 17:08 +0100
                Re: Georgia Tech Software Tools for Primos billg999@cs.uofs.edu (Bill Gunshannon) - 2012-12-14 17:20 +0000
            Re: Georgia Tech Software Tools for Primos billg999@cs.uofs.edu (Bill Gunshannon) - 2012-12-14 12:52 +0000
    Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2019-09-24 14:46 -0700
      Re: Georgia Tech Software Tools for Primos drb@ihatespam.msu.edu (Dennis Boone) - 2019-09-25 04:10 -0500
        Re: Georgia Tech Software Tools for Primos Bill Gunshannon <bill.gunshannon@gmail.com> - 2019-09-25 08:43 -0400
          Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2019-09-25 05:54 -0700
          Re: Georgia Tech Software Tools for Primos Bernard Giroud <bgiroud3@free.fr> - 2019-09-26 10:08 +0200
            Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2021-09-10 20:44 -0700
          Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2021-09-04 11:25 -0700
            Re: Georgia Tech Software Tools for Primos Bill Gunshannon <bill.gunshannon@gmail.com> - 2021-09-10 13:48 -0400
              Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2021-09-10 20:39 -0700
                Re: Georgia Tech Software Tools for Primos Bill Gunshannon <bill.gunshannon@gmail.com> - 2021-09-11 18:16 -0400
                Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2021-10-05 20:54 -0700
  Re: Georgia Tech Software Tools for Primos Daiyu Hurst <daiyu.hurst@gmail.com> - 2012-12-13 17:22 -0800

csiph-web