Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!ut-sally!utah-cs!utah-gr!uplherc!nrc-ut!caeco!john
From: john@caeco.uucp (John Rigby)
Newsgroups: comp.arch
Subject: Re: Bad RISC
Message-ID: <1988Mar4.122513.20600@caeco.uucp>
Date: 4 Mar 88 19:25:12 GMT
References: <216@wsccs.UUCP>
Organization: Caeco, Inc. Midvale, UT.   (Layout. Schem.Cap. Layout Synth. Block.plc.route)
Lines: 113

From article <216@wsccs.UUCP>, by terry@wsccs.UUCP (terry):
> In article <179@wsccs.UUCP> I write:
...
> 
> I have since been asked to post a more complete description of the problem.
> 
> 	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. 

Where do you come up with this nonsense?  The machine does support
byte references, and stores character as bytes not words.
Have you read the SUN-4 assembly
manual or the tried looking at the result of a cc -S on a sample C program.

>                                         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

For your information the SUN-3 sign extends characters passed as arguments
(As do most other 680XX compilers I am familiar with).
If you don't want to do this then pass them as unsigned char's.

> 
> 	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.

What is modulo supposed to mean on floating point values?

> 	3) Non-aligned var-args code not using the varargs definition, but
> 	   rather relying on the method a standard architecture machine has

By "standard" I suppose you mean a machine that your unportable code runs 
correctly on.

From the varargs man page:
	This set of macros provides a means of writing portable pro-
	cedures  that accept variable argument lists.  Routines hav-
	ing variable argument lists (such as printf(3S)) but do  not
	use  varargs  are  inherently  nonportable,  since different
	machines use different argument passing conventions.

> 	   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).

Don't confuse argc, argv with argc, firstarg, secondarg, thirdarg ...
and then setting an argv = & firstarg.  Yes, this works on some
machines, but, that doesn't mean its portable.

> 
> 	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.

When you call anything that doesn't return integer then you had better
declare it before calling it.  In the case of gets() all you need to do
is include stdio.h.

> 
> 	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

WRONG!! They are flaws in your code.

> 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.

Oh, I see, if you or your friends write it, it should run on any machine
no matter how brain damaged the code is.

>| Terry Lambert           UUCP: ...!decvax!utah-cs!century!terry              |
>| @ Century Software       or : ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
>| SLC, Utah                                                                   |

John Rigby
utah-cs!caeco!john