Groups | Search | Server Info | Login | Register

Groups > comp.sys.prime > #163

Re: Georgia Tech Software Tools for Primos

Show all headers | View raw

In article <aa44300f-ff8f-4440-905c-3040c03dae31@a2g2000yqh.googlegroups.com>,
	Daiyu Hurst <daiyu.hurst@gmail.com> writes:
> On Dec 14, 12:11 pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
>> In article <1b811bb7-a9e0-4efb-9e9c-a493e9783...@b8g2000yqh.googlegroups.com>,
>>         Daiyu Hurst <daiyu.hu...@gmail.com> writes:
>> > On Dec 14, 8:07 am, billg...@cs.uofs.edu (Bill Gunshannon) wrote:
>> > 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!!)
> Having gotten my start in an environment where three different
> mainframes had three different character sets, my experience
> taught me not to make assumptions about character sets. And
> I can show you some software written in FORTRAN that also avoids
> assumptions like this, and is fully portable. It compiles and
> runs *as is* on a CDC 6000 machine that has a 6-bit character
> set and on the Prime, without any editing.

So did I.  ASCII, EBCDIC and Field-data.

But that doesn't mean that everyone else did that. Oh, and I have seen
lots of non-portable Fortran in my career.

>> > 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)
> If you have a copy of VMware, you can download this virtual machine
> containing
> Darwin 8.0.1; it has 3 different versions of gcc on it, but if you
> wanted a
> version other than the three supplied, I think you would it more
> difficult to
> get another version to build than you would feel is worth the effort.
> https://docs.google.com/open?id=0ByJs3HoO8aRVck9JSkwyOVBLMUU
> it also has MacPorts installed on it, but most ports will not install,
> since
> they assume you're running MacOSX machine, rather than Darwin.

I have a MAC laptop.  It's OK. but I am no more impressed with it than
any other unix box.  As for MAC apps, they go out of their way to make
their stuff non-portable.  It's a religious thing.

On the unix side I run various falvors of Linux, OpenBSD, NetBSD, FreeBSD,
BSD-2.11, SunOS, SOLARIS, Ultrix-11, Ultrix-32, XENIX, Version7 and I think
there is still a SYSTEM-III floating around.  In the past I have also done
IRIX, AIX, DomainIX and, of course, PRIMIX.  Guess which one was the only
one that needed major re-writes of even the most trivial of programs to
to make them work.  :-)

>> > 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?
> Again, this is due to poor design assumptions by the original
> programmer.
> The value of the expression  [literal "A" minus literal "@"] is always
> the
> same, whether its on a Prime or on MS-DOS.

Which means nothing when the switch statement looks at chars and assumes
the numeric value is between 0 and 127.  I am still waiting for someone
to explain to me just what Prime thought they were accomplishing with
that mark parity stuff.  Of course, the native Unix that was never allowed
to be released got rid of it and the 50-series ran just fine without it.

>> > 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 actually has a number of APIs; of course I really meant to
> say, the
> web is the universal applications platform. I think you can even do
> stuff
> like EDI and CICS via webapps now.

And every different system and OS requires a program to do that.  With
a common API the same program could be compiled without modification on
any of them.

>> > 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.
> In which case they're just going to be lazy and not do as I outlined.
>> >                      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.)
> Ah, expediency makes it ok.
>> >> 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.
> I don't think Prime's software technology played any role in their
> demise.
> Bad business decisions and the LowBlow takeover was what killed them.

Trust me it did.  They were often seen as the odd man out.  I watched them
loose RFP's even when they outperformed their competitiors (usually a VAX).
One of the problems was, again, all the applications available for Unix
already (many free) that could not even be made to run on PRIMOS.  Good
hardware and nice OS are meanngless without the tools to do real work.
And if the tools are rare or have to be totally re-engineered then they
also come with a high price. Strike two.

>> > 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.
> One's order is another's chaos.
>> >                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.
> I misstated that I meant to say, there is no single portable solution
> to
> this. Each system tends to provide its own way. So in fact there is no
> "Unix Way" to check for a keypress, process the keypress if it
> happened,
> but not echo it back out again, unless the program does so itself.

You have to go all the way back to when AT&T was still doing SYS-V
development for that to be true.  AT&T did a lot of things different,
deliberately, in order to try and hold onto a market.  Remember STREAMS?
Once Berkeley became pretty much the standard everybody did it in a
pretty standard way.  And still, there is more than one way.  Of course,
if you are running local echo, all bets are off.  :-)

>> > 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.
> yes, I misstated the problem. It's doable on every system, but there
> seems
> to be no universal way to do it. Look at the variety offered here:
> http://stackoverflow.com/questions/421860/c-c-capture-characters-from-standard-input-without-waiting-for-enter-to-be-pr

I just took a quick glance and they all seem to be doing ti the same way
with additional coding that appears to be programmer choice rather than
required by the OS.  And one was Windows which would have to be different.

>> > 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.
> If you're writing an machine emulator, and you're going to run an
> operating
> system on it, and that operating system wants to talk to a keyboard,
> and
> do so in either half-duplex (and thus not echo the characters) or in
> full-duplex
> (and thus echo the characters). The decision to echo shouldn't be made
> by the
> runtime library of the language you wrote the emulator in, or the
> operating
> system of the computer that hosts the emulator. The decision needs to
> be made
> by the operating system running on the emulator.
> I hope that's clearer.

Yes, and where is that not the case?  Control of character echo is done
by the OS on Unix, not by the C language.  


>> >> 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.  :-)
> OS designers have been picking and choosing what bits from POSIX they
> wish to implement. Yes, generally, for whatever portions DO get
> implemented,
> those tend to respond as expected. 

That's one flaw in POSIX, but it is politics and not technical.  There
is no requirement to do all of it and they even established levels of
compliance.  But trying to force an all or nothing deal never works either.
Look at Ada.

>                                    I tend to think another reason it
> works
> well is due to the lack of diversity in processor architectures these
> days.

Well, if your world is limited to PC's, that may be true.  But then some
of us still have things like the VAX, Alpha, Itanium, SPARC, M68K and
PDP-11.  And then you have the embedded world.  8051, ARM, RM7035C :-)
and heaven only knows how many others.

>> > 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.
> PJ Denning had an interesting, fatherly perspective on this:
> "You may have wondered why virtual memory, so popular in the operating
> systems of the 1960s and 1970s, was not present in the personal-
> computer
> operating systems of the 1980s. The pundits of the microcomputer
> revolution
> proclaimed bravely that personal computers would not succumb to the
> diseases
> of the large commercial operating systems; the personal computer would
> be
> simple, fast, and cheap. Bill Gates, who once said that no user of a
> personal
> computer would ever need more than 640K of main memory, brought out
> Microsoft DOS in 1982 without most of the common operating system
> functions,
> including virtual memory. Over time, however, programmers of personal
> computers encountered exactly the same programming problems as their
> predecessors in the 1950s, 1960s, and 1970s. That put pressure on the
> major PC
> operating system makers (Apple, Microsoft, and IBM) to add
> multiprogramming
> and virtual memory to their operating systems. These makers were able
> to
> respond positively because the major chip builders had never lost
> faith; Intel
> offered virtual memory and cache in its 80386 chip in 1985; and
> Motorola did
> likewise in its 68020 chip. Apple offered multiprogramming in its
> MultiFinder
> and virtual memory in its System 6 operating system. Microsoft offered
> multiprogramming in Windows 3.1 and virtual memory in Windows 95. IBM
> offered multiprogramming and virtual memory in OS/2."
> and
> "From time to time over the past forty years, various people have
> argued that
> virtual memory is not really necessary because advancing memory
> technology
> would soon permit us to have all the random-access main memory we
> could
> possibly want. Such predictions assume implicitly that the primary
> reason for
> virtual memory is automatic storage allocation of a memory hierarchy.
> The
> historical record reveals, to the contrary, that the driving force
> behind virtual
> memory has always been simplifying programs (and programming) by
> insulating algorithms from the parameters of the memory configuration
> and by
> allowing separately constructed objects to be shared, reused, and
> protected. The
> predictions that memory capacities would eventually be large enough to
> hold
> everything have never come true and there is little reason to believe
> they ever
> will. And even if they did, each new generation of users has
> discovered that its
> ambitions for sharing objects led it to virtual memory. Virtual memory
> accommodates essential patterns in the way people use computers. It
> will still be
> used when we are all gone."
> (taken from "Before Memory was Virtual"
> http://denninginstitute.com/pjd/PUBS/bvm.pdf

Cute story, but nothing new to anyone who has been in this business for
more than a decade.  And irrelevant to the issue of wether or not a
standard API is useful.  :-)

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