Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!asuvax!mcdphx!udc!chant!aglew
From: aglew@urbana.mcd.mot.com (Andy-Krazy-Glew)
Newsgroups: comp.arch
Subject: Re: VLIW Architecture - References, oth
Message-ID: <AGLEW.89Oct18194319@chant.urbana.mcd.mot.com>
Date: 18 Oct 89 23:43:19 GMT
References: <771301127@8909291517.AA00260@maxwell.ece.c> <130800001@peg>
Sender: aglew@urbana.mcd.mot.com
Organization: Work: Motorola MCD, Urbana Design Center; School: University of Illinois at Urbana-Champaign
Lines: 46
In-reply-to: robert@peg.UUCP's message of 14 Oct 89 12:33:23 GMT

>Why should we welcome a continual increase in MIPS (VUPS or whatever)?
>We have enough trouble designing programs which work without error at the
>moment.  These will just get to the error state faster with more power.
>Instead of pushing for a continual increase in power, how about looking
>at, for example (and this is *only* an example), better hardware to aid
>program correctness and completeness.

...hardware to aid program correctness and completeness:

    Like, array bounds checking?  Overflow detection for integers?

    	All of this can be and has been done on existing systems.
    	No need for special hardware support. But still, the vast
    	majority of programs in the USA [*] run without any of these
    	forms of compiled in security.
    	    Why? Programs run faster when run-time checks are turned off.
    	QED.
    	    Several compiler systems do a damned good job of removing
    	run-time checks that they can prove to be unnecessary. Maybe one
    	day I'll be able to use one. But until then, improved run-time
    	checking requires improved performance.
    	    "But not just brute force - maybe special, parallel, hardware?"
    	Maybe - but if the extra hardware slows you down by factor X,
    	and the cost of inline checks in a serial instruction set are
    	Y<X, then people will build faster serial processors - and still
      	customers will turn off the run-time checks.
    	    This is one of the things I find encouraging about the trend 
    	to VLIW (I consider machines like the new IBM chip with multiple
    	slots semi-VLIW): so maybe your compiler cannot fill all the 
    	slots all the time.  Maybe we could put run-time checks into some
    	of the unused slots, with no loss of performance due to extra 
    	instructions.  Then, if there is a $$$ benefit from the checks,
    	maybe we'll start using not just idle resources for them.

    	[*] Note that I didn't say all, and that I carefully restricted 
    	    it to the USA.  Not that I believe that the majority
    	    of programs outside the USA use run-time checks, but I have
    	    heard about systems, like Northern Telecom's, that use
    	    run-time checks in production code. Encouraging. 

--
Andy "Krazy" Glew,  Motorola MCD,    	    	    aglew@urbana.mcd.mot.com
1101 E. University, Urbana, IL 61801, USA.          {uunet!,}uiucuxc!udc!aglew
   
My opinions are my own; I indicate my company only so that the reader
may account for any possible bias I may have towards our products.