Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!mailrus!tut.cis.ohio-state.edu!ut-sally!utah-cs!utah-gr!uplherc!sp7040!obie!wsccs!terry
From: terry@wsccs.UUCP (terry)
Newsgroups: comp.arch
Subject: Bad RISC
Message-ID: <216@wsccs.UUCP>
Date: 28 Feb 88 01:31:18 GMT
Lines: 123
Keywords: SUN RISC

In article <179@wsccs.UUCP> I write:
>We have been able to port to all machines we attempted, except ...  SUN's new
>... RISC machine ...
>
>THE REASON:  Type-casting.  You can't.  Small programs seem to, but it doesn't
>work.  Bytes tend to be word aligned.  Other messy stuff.  It was not a
>pretty sight (site?).  I am sure there are other problems, but geez, this is
>demonstrably portable code.

I have since been asked to post a more complete description of the problem.

> Could you post a more complete description of the problem?
> -- 
>   Lawrence Crowl		716-275-9499	University of Rochester
>		      crowl@cs.rochester.edu	Computer Science Department
> ...!{allegra,decvax,rutgers}!rochester!crowl	Rochester, New York,  14627

	Ok, here goes.  I can't give an exact example, as I have signed a
non-disclosure agreeement.  The RISC machine primarily attacked my boss,
not me, so I can't fake one up that I can guarantee to work.

	1) The processor thinks in words (bus-words) always;  this means if
	   you want to do something, even if it is manipulation of character
	   data, it is stored in words.  The problem comes in that the C
	   compiler on the machine did not make that distinction, and broke
	   on parameter passes to functions, where a single character element
	   is sign-extended to int to be passed.  This means that the top bits
	   were not cleared.  As this was the portable C compiler, I blame it
	   on the architecture not taking normal (read existing) operations
	   into account.  If the chip supported byte references, this would not
	   have happened.

	2) Implicit type casting, which tries to take advantage of the register
	   architecture of the machine it runs on does not always work as is
	   expected:

		float val = 314.15926535;
		float j;

		j = val % 75.0123;

	   or something similar using an integer-only operator does not
	   correctly truncate values past the decimal.

	3) Non-aligned var-args code not using the varargs definition, but
	   rather relying on the method a standard architecture machine has
	   of plunking arguments into a function (no, I do *NOT* refer herein
	   to the argument push order!) stack to be read by a function leaves
	   it indeterminate as to whether the function arguments are pointers
	   or what.  For instance

		int foo;

		foo = 'x';	/* possibly buggy implicit cast*/

		printf( "the character %c has an ascii value of ");
		printf( "%d decimal and %x hex", foo, foo);

	   apparently works, but if you write your own function output and call
	   it in place of printf, using the argc/argv style of parameter
	   passing, the processor apparently confuses the stack.  (Yes, I
	   _know_ function prototypes would probably alleviate this, but
	   until some kind soul rewrites all the C code out there, I will
	   almost always be referring to K&R C).

	4) Passing back pointers from functions whose type is resolved by the
	   linker is dangerous (I don't write code like this anyway, but if
	   you want an example try 'gets()'), and passing integer values back
	   to character assignment statements (getc()) is also unhappy.

	I realize that most of my examples are vague;  I don't keep broken
code around so I can pull it up as an example; I 'rm' it.  The only examples
of code that wouldn't port belong to another company, so I can't post them so
you can break it yourself.

	I also realize that even if you accept my examples at face value, they
appear to be flaws in the portable C compiler, some of which can be taken out
simply by adding an baroque code generator capable of producing the workarounds
for you... macro's to replace the instructions which aren't there because it is
a RISC machine.  Such macro's sort of defeat the purpose of having a RISC
machine... what's the use of having a 'more compact' instruction set if you
just have to generate more of them?

	While a new code generator is an agreed upon necessity for a new
processor, the compiler itself should not have to be changed... quad's are
supposed to be quad's.  If you have to change the compiler, you may avoid
changing your own code, but obviously you still have to change code (the
compiler) which is supposed to be portable anyway.

	I think the whole problem could have been avoided if SUN had seen
fit to provide byte/short manipulation instructions, even primative ones,
in their chip.  If they're there, the should have provided dos on them to
the guys who had to write the code generator.  Either way, users are going
to pay the price in execution time if they have to have an additional layer
of instructions between their executable code and their machine.

	I can't really be a bigot about having to write extra code to make
a machine do something it apparently wasn't designed to do... after all, I
run MS-DOS on my Amiga and dBase III .cmd files on a VAX ...but I feel that
either their developement tools need a rewrite (how are you going to fix the
assembler? :-) ) or the manner in which RISC design at Sun is approached
needs reconsideration.

My definition of portable:  Everthing I write, everthing my friends write, and
everthing I run that was written by somebody else, should run with minor
changes.  These changes should only be necessary as symptoms of differences
in O/S implementation philosophy, and not as differences in basic structure.
The programmer should know about the hardware he is running on in order to
make appropriate design decisions as far as speed of operation, but he should
not be _required_ to know (brow-beaten into it).  A user should never know,
or even suspect.  If a company says they run UNIX V.3, I should be able to
take my UNIX V.3 software off my 3B2 (or Arete 1100, or NCR Tower, etc) and
compile it with the same flags and have it run exactly the same.

Other definition of portability:  If it ran on UNIX and you ported it to VMS
so that all you had to do was #define UNIX or VMS, it should be relatively
trivial to port it to other machines, even those running Atari DOS wedge on a
6502 :-).

| Terry Lambert           UUCP: ...!decvax!utah-cs!century!terry              |
| @ Century Software       or : ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |