Dying Architectures

COTTRELL, JAMES cottrell at NBS-VMS.ARPA
Tue Oct 8 09:20:48 AEST 1985


/*
> >From: ray at othervax.UUCP (Raymond D. Dunn)
> >It is intersting to note in the discussions re short, longs etc. that
> >portability seems to be regarded as a major reason-d'etre for much
> >coding activity.
> >
> >All very well if portability can become ingrained in our way of thinking
> >just as block-structuring has now become (to some), but it should be noted
> >that in this big bad commercial world we (some of us) live in, very few
> >software projects can afford to schedule "extra" time for designing in, and
> >testing, the portability of code.  Yes, in the long run, it is maybe
> >worthwhile, but often it falls into the same category as generalising your
> >code as opposed to making it specific - a good thing to do, but often
> >commercially/practically unjustified.

While I am generally not a strict portability freak, I would have to
agree with the first clause of the preceding paragraph. That is,
Portability as context for prgramming, as opposed to content. When you
do it right the first time, you don't have to go back or budget extra
time. I doubt if it takes Guy Harris any longer to write portably, he
just *thinks* that way. 

> Astounding! I guess you have a right to your opinion, what company do
> you work for and exactly what processor is your code tied to so I know
> exactly when to sell short on your stock? DEC-20? IBM7094? Z80? TIMEX/1000?
> DEC-10? 8008? PDP-8? DG/NOVA? SDS(XDS)? need I go on....

Good point, but you are mentioning dinosaurs. With the exception of the
Z80 & the DEC machines, (well maybe NOVA, but they are rare) all these
machines are dead. Maybe that was your point. See below.
 
> Maybe you should have a little chat with some of the vendors of code for
> those machines about portability and it's relationship to commercial
> survival, as the old expression goes, you more likely can't afford *not*
> to spend the extra time. Sit down and extrapolate the life span of a processor
> coming to market today (hint: it's shrinking.)*
> *exception: ibm370 architecture, give or take XA I assume it will be around
> forever, tho that still might exclude new markets for your software.
 
It is often said that the whole world is not a VAX. Too bad. That's like
saying all (wo)men are not saint(e)s. It all started with the PDP-11,
which defined the basic instruxion set architexure for practically all
new machines. Take a look at the 68000 & say, `this is a pdp-11.'
Take a look at the National 32032 & say `this is a VAX'. Take a look
at the Zilog z800[0[0]] & say `this is a PDP or a VAX'. The basix of
these machines seems to be:

	1) an array of <power of two> registers.
	2) 8 bit bytes, 16 bit words, 32 bit longs
	3) stack pointer with pre-decrement push, post-increment pop
	4) NZVC condition codes set by computational instruxions
	5) 16 branches testing the above
	6) monads: clear, negate, complement, increment, decrement, test,
		shift/rotate left/right
	7) dyads: add, sub, mul, div, and, or, xor, mov, cmp
	8) aux: jsr, rts, jmp

Variations exist and are relatively minor compared to the similarity.

> Perhaps more practically, if you can learn to code reasonably portably,
> you usually can avoid the major pitfalls and fix a piece of code to be
> actually portable when the need arises without too much trouble (no
> flames, I know, a 200,000 line system would be better off portable to
> start, but if it's reasonable it could be fixed *more* easily than re-written.)
> 
> 	-Barry Shein, Boston University

Couldn't agree more with this paragraph. Especially the last statement.
I might add, tho, that even a program with serious portability problems
is easier to port than rewrite from scratch (assuming that it measures
up on other grounds, like modularity).

	jim		cottrell at nbs
*/
------



More information about the Comp.lang.c mailing list