NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/prime/2657

Internet Message Format | 1992-12-23 | 6.0 KB

Path: sparky!uunet!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!werple.apana.org.au!news
From: [e-mail] (Mark Delany)
Newsgroups: comp.sys.prime
Subject: Re: X Windows on 50-Series
Date: 23 Dec 1992 21:12:35 +1100
Organization: werple public-access unix, Melbourne
Lines: 136
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: werple.apana.org.au

[e-mail] (Jason Pascucci) writes:


>PL/P is the highest used Primos language, with 1448 modules as of 23.3,
>382 SPL, 373 PMA, 175 FTN, and 99 Modula. (Not including insert files)

Jason, thanks for presenting these figures. Pretty interesting in
there own right really aren't they?

As someone pointed out in private mail, this is obviously a moving
target and in the last number of years people have made a great
efforts in converting much of the old FTN.

>In many cases, the 'right language' for the 'right job' was used.

That may be true today, but to be strictly honest, in the early days
there was no choice but FTN and PMA.

let's face it, FTN's is a god-awful OS language as is evident by the
efforts spend re-coding a lot of the FTN into one of the other
languages.


>I am a proponant for multiple languages in software products...
>admittedly, it is a maintenance problem, but more importantly
>no one language has all the capability to do it all, and still come
>out looking reasonable. Personally, I'd pick SPL over C in about 80%
>of the cases of software development, from OS to apps.

Yes, remember the compiler wars? I guess it's safe to reminisce over
them now, isn't it?

Tell me something. I can understand the philosophical differences
regarding (say) Module II vs PLP, but I really struggle to understand
why all that energy went into both SPL *and* PLP. I found the
differences vastly more annoying than useful.

At the time people were vehement, but surely much of the argument was
nits which could have been solved?

>|> Let see, that adds up to 24*80 * 8*13 * 8 bits (xy * font * colour
>|> planes), or approx 200Kb. Pretty difficult when the largest contiguous
>|> pieve of memory you can do in V-mode is 128Kb!

>Which is easily enough coded around. However, this isn't much of an
>issue for X, since the X stuff is in IX (c-language support) mode.(Come
>to think of it, I don't know if IX handles this any better, either.)

Memory fade notwithstanding, IX mode still had the V-mode segmentation
model. I was under the impression that X-mode was the only mode that
gave a contiguous memory model, but that never saw the light of day.
Sad really, it looked good.

>However, add scrollback to that '24' number, also. I personally use
>at least 200 lines, and I know someone who uses upwards of 1000.
>Viva la VM!

VM - yes, programmer visible segmentation - no. Especially not these
days.

>(Thinking about it a little more, you'd allocate this in chunks
>anyways, not a flat space.)

Of course, But to generalize, what you should be doing is selecting
the structure that best solves your problem, certainly not one
enforced by H/W limitations. You can chunk in flat but you can't flat
in chunk.

But I don't think anyone seriously argues that a segmented model is
more convenient for the programmer than flat address space (how the
H/W provides this along with memory protection etc, is its business).

The advantages of fix length segments (if you will) is one of H/W
convenience and simplicity.

On a tangent, you may want to see the old discussions re 64-bit
addressing in comp.arch, one suggestion was that every data bit in the
universe would be potentially visible in one huge address space! The
mind boggles really.

>|> I'll bet that reasons like: fork(), select(), device independence
>|> [consider read()/write() of sockets], exec(), pipe() and wait() also
>|> have a part to play as just about any Unix prog with a degree of
>|> difficulty greater than zero relies on some of these (Xlib uses at
>|> least two of these for starters).

>These have for the most part been worked around previously, for
>PRIMIX support. Others have been done also. Many of these
>are fairly useful...I'll ask around about getting them released.

Er, for some part and partially. And then often only within the
confines of Primix or the C-library.

>|> Would Alan Dossett care to elaborate on the reason for most of the
>|> problems. It would certainly help those the poor sods who are trying
>|> to port other Unix code to Primos...

>My take (I'm not directly working on the project) is that the
>C compiler is giving most of the headaches. Much of the
>#ifdef __50SERIES ... #endif is to get around compiler issues.
>One of the problems with finding the problems was the enormous
>number of macros to get to the actual code, and the non-intuitiveness

Yes, there is one particularly famous macro in there somewheres that's
literally pages long. The mother of all macros as far as C compilers
are concerned.

Now here's a truly insidious thought. Perhaps the Primos C compiler's
symbol table overflows a 64K segment size with this sucker (I recall
that BIGPMA existed solely because normal PMA had this problem).


>of the placement of those macros in the source code distribution. Another
>was, if memory serves, an alignment problem in structures. Some of
>these problems have only arisen as of the later version of the
>C compiler.

>Alan, maybe you can get someone working on X to summarize
>some of their porting issues here?

Something I've always wanted to know is why the port of Unix to
50-series was canned (and I don't mean PRIMIX, I mean the genuine
article). Now what was that project called? Here are my three guesses:
performance, politics and (you guessed it) segmentation.


>It's kind of nice to hear
>that there are people out there who are actually porting code
>*FROM* a Unix box. :)

Actually, being Christmas and all, I was thinking of others :-)



--
Mark Delany                                          [e-mail]