VLIW Architecture - References, oth
rob...@peg.uucp
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.
The problem is the same, as far as I can see, as that of most of economics.
Economics traditionally has growth being the sole reason for existance. If
there is not a steady growth in an economy the that economy is dead, as far
as t.e. is concerned. Forget that that economy may actually be doing the
best things for all the people in it etc.
This should not be in here, perhaps, but again, let's use what we have
(and understand it fully) BEFORE moving on. Look ahead, don't leap.
Robert McArthur
Pegasus Networks,
Byron Bay, NSW, 2481
Australia
Donald Lindsay
In article <130800001@peg> rob...@peg.UUCP writes:
>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.
Well. Speaking as someone who has spent a lot of his life finding
other people's bugs: I disagree completely.
More mips didn't just take us from slow to fast. It also took us into
new worlds. Compare a MacIntosh to a hardcopy terminal that
timeshares BASIC from a PDP-8. Speed means that the human is catered
to. I don't see that this has come to an end, either.
Further, real experience says that I'd rather debug on a fast machine
than a slow one, all else being equal. I hate waiting minutes for
breakpoints to hit: I hate waiting overnight for rebuilds: I hate
waiting days for test suites to complete. Heck, in the old days, we
didn't HAVE much in the way of test suites - it took too long to run
them, and it took too long to develop "unessential" code on @#$%^&
batch machines. Besides, speed allows us luxuries like coverage
tools.
About the only hardware feature I used to pray for was "breakpoint at
data address". It turns out that there are several ways to do this on
conventional hardware.
--
Don D.C.Lindsay Carnegie Mellon Computer Science
Steve Warren
>
>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.
This is most humorous ;^). You should post this to rec.humor. But you
left out the smilies.
It is especially funny to think of the billions of dollars everyone is
spending collectively on computing hardware, when all that is ever
accomplished is errors ;^). Seems like after a while we would all
realise that nothing is being generated except errors, and we would
all take up basket weaving ;^).
--Steve
-------------------------------------------------------------------------
{uunet,sun}!convex!swarren; swa...@convex.COM
Henry Spencer
>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.
Many of us have little reason to rejoice at higher power, at least until
the software catches up and lets us make intelligent use of all those
extra cycles. (There is much more that the software could be doing for
us.) However, those who do need more power need it *very badly*. The
computational-aerodynamics people, to take one example, would be overjoyed
to be able to buy processors 1000 times the speed of existing ones.
--
A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology
megabyte of flaming. | uunet!attcan!utzoo!henry he...@zoo.toronto.edu
Robert Colwell
>In article <130800001@peg> rob...@peg.UUCP writes:
>>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.
>Well. Speaking as someone who has spent a lot of his life finding
>other people's bugs: I disagree completely.
>Further, real experience says that I'd rather debug on a fast machine
>than a slow one, all else being equal.
Agreed, as far as that goes. We've hashed this out before on this forum,
and believe me when I say I really don't want to do it again, but...there
have been computer systems designed with their major aim being minimization
of the life-cycle cost of the system, software and hardware included. (I'm
thinking of the object-oriented systems here.) You can argue that no such
system has yet measurably achieved such an objective, and you may well be
right. But that's not the same as arguing that improving the performance
of a machine is the ONLY way to improve its life-cycle cost. Do you really
believe it is?
Bob Colwell ..!uunet!mfci!colwell
Multiflow Computer or col...@multiflow.com
31 Business Park Dr.
Branford, CT 06405 203-488-6090
Ron Guilmette
>data address". It turns out that there are several ways to do this on
>conventional hardware.
I noticed that the i860 has this feature on-chip. I don't know if it
is available with the CMMU's for other current 32-bit micros (e.g. 88k,
MIPS, SPARC). If anyone else knows, please tell me.
Now if we could just get support for such things via standard UNIX ptrace
calls, and then get the GNU Debugger (gdb) to actually bring such facilities
out to the user's level...
// rfg
John R. Levine
>In article <65...@pt.cs.cmu.edu> lin...@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes:
>>About the only hardware feature I used to pray for was "breakpoint at
>I noticed that the i860 has this feature on-chip. ...
>Now if we could just get support for such things via standard UNIX ptrace
>calls, and then get the GNU Debugger (gdb) to actually bring such facilities
>out to the user's level...
Some of us low-budget types feel pretty lucky. The 80386 can trap up to four
memory addresses, separately monitoring each for fetch, read, or write.
When this feature is in use your program runs slower, but it's a heck of
a lot faster than instruction at a time tracing.
Astonishingly, AT&T System V/386 ptrace() lets you read and write the debug
registers (take that, you Berkeloids) that control this swell feature.
I keep meaning to teach gdb how to use them. Maybe somebody else already
has.
--
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
jo...@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
Massachusetts has over 100,000 unlicensed drivers. -The Globe
Craig Jackson drilex1
>
>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.
I never meant to imply that hardware devoted to program correctness was
unappreciated. I personally do most of my work on the Unisys A-Series,
which offers such things as hardware array-bounds checking. However,
they found that they had to defeat that feature to make a usable C compiler...
I welcome any hardware support of program testing and analysis. I feel that
many of today's MIPS could be better spent adding a few gate-delays for
such features.
However, that aside, I also like writing programs on machines that have
enough speed to produce a decent user interface without coding
balls-to-the-wall (introducing more complexity). I like writing programs
on machines which have enough speed to allow me to leave all of my
internal assertion checks in the finished program. I like writing programs
on machines which are fast enough to have sophisticated programming-
support tools. (Not that many of those have been written yet.)
>The problem is the same, as far as I can see, as that of most of economics.
>Economics traditionally has growth being the sole reason for existance. If
>there is not a steady growth in an economy the that economy is dead, as far
>as t.e. is concerned. Forget that that economy may actually be doing the
>best things for all the people in it etc.
I used to have poster with the slogan "Growth is the only evidence of life".
Not that this is really true, but it does give one thought.
I think you should think of this desire (on the part of politicians,
economists, and hardware-designers) as the desire to each day, leave the
world a little better than the day before. I think that the view that
growth is undesirable comes from differences of opinion about what is
better for the world.
>This should not be in here, perhaps, but again, let's use what we have
>(and understand it fully) BEFORE moving on. Look ahead, don't leap.
>
>Robert McArthur
>Pegasus Networks,
>Byron Bay, NSW, 2481
>Australia
>
>rob...@peg.pegasus.oz.au
--
Craig Jackson
dri...@drilex.dri.mgh.com
{bbn,ll-xn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
Barry Shein
The correct way to state the "do we need more MIPS?" argument is
something like this:
1. There exists a percentage of users who, no matter how fast
computers become in the foreseeable future, will need even more speed.
2. There are two factors making the percentage smaller over time, the
steady and rapid increase in office and other clerical uses of
computers and the increase in speed we are seeing (that is, some users
are dropping out of the hunger category simply because they have
become sated for the time being.)
3. A good test of whether or not someone is in the first category or
not is to ask the question: "Given $X for your computing needs, and no
more, for the next year what would you spend it on?" If they say CPU
then they're probably in the first category. If they say a faster CPU
would be nice but I guess right now I'd have to buy (some neat
applications software, more disk, printer, whatever) then they're
probably not in the first category, just like to think they are.
Many more people are in the "just like to think they are" category
than most of us are led to believe. They say that CPUs must get faster
but, instead of buying faster CPUs already available, they buy things
like nifty laser printers or graphics packages for the same dollars.
Granted the shrinking percentage of power-hungry users still control
hefty dollars and that's what keeps that section of the industry
humming but don't discount the trends. There may well be a point
beyond which even folks like DOD can't keep the sheer race for MIPS
viable. I/O bandwidth is probably another competing frontier.
--
-Barry Shein
Software Tool & Die, Purveyors to the Trade
1330 Beacon Street, Brookline, MA 02146, (617) 739-0202
daniel mocsny
> 1. There exists a percentage of users who, no matter how fast
> computers become in the foreseeable future, will need even more speed.
This I agree with, though I think the percentage is 100.
> 2. There are two factors making the percentage smaller over time, the
> steady and rapid increase in office and other clerical uses of
> computers and the increase in speed we are seeing (that is, some users
> are dropping out of the hunger category simply because they have
> become sated for the time being.)
OK. Let's distinguish clearly between how much computer we "need," and
how much we "can use." The reason office and clerical users are
getting saturated right now is not because computers have solved all
their problems and they are now sitting around twiddling their thumbs.
If anything, these workers still appear to have plenty of remaining
profitable opportunities to apply Information Power. The problem is,
viewing the computer as an ergonomic device, to get the computer to do
X amount of work, the user must sit there and perform f(X) amount of
work (typing in commands, searching for and reading TFM, wondering why
the serial cables don't work, waiting on hold at the user support
number, unjamming the printer, looking for backup copies of trashed
files, etc. etc.). The amount of work the user can perform then limits
the amount of computer power the worker can productively exploit.
Because the overall ergonomic performance of computer systems today
is still rather poor, very few people have the type of scalable, redundant
problems (such as airline ticketing or weather forecasting) that allow
a handful of computer operators to effectively use powerful hardware.
To say that people don't "need" any more computer power is to say that
they have no further aspirations. That is plainly silly. As soon as
hardware/software reduces f(X) for one task enough to give the user
some spare time, the user will then advance to the next profitable
task. The real problem is that the industry cannot produce
general-purpose computing machines that keep themselves doing useful
things at full tilt without requiring constant attention from highly
skilled users.
Dan Mocsny
dmo...@uceng.uc.edu
Andy-Krazy-Glew
>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, ag...@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.
Donald Lindsay
In article <1989Oct17....@esegue.segue.boston.ma.us> jo...@esegue.segue.boston.ma.us (John R. Levine) writes:
>>In article <65...@pt.cs.cmu.edu> lin...@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes:
>>>About the only hardware feature I used to pray for was "breakpoint at
>>>data address". ...
>The 80386 can trap up to four
>memory addresses, separately monitoring each for fetch, read, or write.
>When this feature is in use your program runs slower, but it's a heck of
>a lot faster than instruction at a time tracing.
Hmm, I wonder how much slower?
The above quote from my posting leaves off the comment that it can be
done *without* special hardware features. In particular, the infamous
trap-after-every-instruction feature is a bad idea, because this
"hardware assisted" method is sooo slooowwww.
1) I believe that Encore's debugger simply has a spare processor
watch the location.
2) A compiler generating debug code, can put a special call at the
front (and rear) of each subroutine. The debugger provides the
routine that is called: if you ask to have a location monitored, then
that's what the routine does. As debug services go, this takes very
little space and very little time - especially on machines with
lightweight call instructions. Admittedly, it can only say "the
variable changed in procedure foo, between its call to baz and its
call to bletch". But, when I used it, that was great information.
3) The debugger could protect the variable's page, and catch the page
faults. Admittedly, a particularly popular page could cause a
performance problem. However, several times, I was looking for one
wild dereference into maybe four megabytes of tree. On a VAX, that
one locked page would have taken up a whole 0.0001 of the address
space.
My point: there are a lot of ways to skin a cat, and extra hardware
is usually only one of them.
Sean Fagan
>memory addresses, separately monitoring each for fetch, read, or write.
>When this feature is in use your program runs slower, but it's a heck of
>a lot faster than instruction at a time tracing.
>Astonishingly, AT&T System V/386 ptrace() lets you read and write the debug
>registers (take that, you Berkeloids) that control this swell feature.
>I keep meaning to teach gdb how to use them. Maybe somebody else already
>has.
This is a brief pseudo-plug, followed by a real question...
Anyway: CodeView(tm) under SCO UNIX 3.2 uses the debug registers to set
'Watchpoints' and 'tracepoints.' I think it also uses other debug registers
to set breakpoints. A problem with this is that there are only 4 register
(of each kind, I believe: 4 code breakpoint and 4 data breakpoint, but I'm
not sure), thus you can only set 4 breakpoints... BTW, it is a very nice
feature. I first saw something like it in dbx on a Sun (trace <var>), but
using it slowed it down incredibly (it had to single step, I believe). With
codeview, it runs along at full speed until it accesses the variable.
*Very* nice.
Lots of other processors have these, of course, including, say, the NS32xxx
series. My chief complaint is that they only catch a single address; I
think they would have been much more useful if it had been <address,
length>. For a real-world example, I could then tell codeview to stop
whenever any element of a structure has changed. Anybody got a reason why
it never seems to be implemented that way, other than not slowing it down (I
would not be surprised if it slowed down memory accesses by 1 or 2 cycles)?
--
Sean Eric Fagan | "Time has little to do with infinity and jelly donuts."
se...@sco.COM | -- Thomas Magnum (Tom Selleck), _Magnum, P.I._
(408) 458-1422 | Any opinions expressed are my own, not my employers'.
Barry Shein
>To say that people don't "need" any more computer power is to say that
>they have no further aspirations. That is plainly silly. As soon as
>hardware/software reduces f(X) for one task enough to give the user
>some spare time, the user will then advance to the next profitable
>task. The real problem is that the industry cannot produce
>general-purpose computing machines that keep themselves doing useful
>things at full tilt without requiring constant attention from highly
>skilled users.
>
>Dan Mocsny
It's not that they have no further aspirations, it's that they have no
further software. And that's not silly.
You can hypothesize all this software which "they" will find useful
and will require all these extra cycles but it remains just that, a
hypothesis, an extrapolation of past experience which may or may not
be valid. I will grant it will be valid in some applications domains
but in others it may very well not be valid.
In fact, they'll scream for more cycles *after* that software shows
up, not in anticipation of it.
If we have to hypothesize non-existant software to soak up the cycles
we already have, then we have entered a very different realm indeed
from a very few years ago.
The current thinking in this field is reminiscent of the "rising
expectations" of the 60's where the common view was that of
ever-expanding, limitless resources and economies. (More) prosperity
is just around the corner.
I'm not saying this thinking is wrong, but I am saying its proponents
seem unexamined, zealotry is a word which comes to mind.
--
-Barry Shein
Software Tool & Die, Purveyors to the Trade | b...@world.std.com
1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs
daniel mocsny
> It's not that [ users ] have no further aspirations, it's that they have no
> further software. And that's not silly.
I'm sorry if the tone of my post sounded excessively hostile. I see now
that I misunderstood your use of the word "need." When I am hungry, but
have neither food nor a dish to put it on, I still need to eat. However,
I guess if I speak of needing a dish, I mislead.
> You can hypothesize all this software which "they" will find useful
> and will require all these extra cycles but it remains just that, a
> hypothesis, an extrapolation of past experience which may or may not
> be valid. I will grant it will be valid in some applications domains
> but in others it may very well not be valid.
The past history of the computer industry has many amusing episodes
beginning with statements like: "Nobody will ever need ... " or "The
maximum worldwide demand for < X > will be at most ... "
Prognosticators have been very good at underestimating the demand for
information processing power. I am understandably skeptical when I
hear similar statements today, especially when I am acutely aware that
my own information needs are far from satisfied (a function of both
inadequate hardware and inadequate software).
However, I agree with your concern about the software lag. The software
complexity necessary to fully exploit powerful computers appears to
increase in proportion to those machines' power. And yet, as we all
know, while the hardware power increases exponentially, software
complexity increases arithmetically (if at all).
> In fact, they'll scream for more cycles *after* that software shows
> up, not in anticipation of it.
This is true. Both users and experts have a profoundly difficult time
grasping the potential of any new development until it is up and running
before their eyes...or perhaps, before their competitors' eyes...
> If we have to hypothesize non-existant software to soak up the cycles
> we already have, then we have entered a very different realm indeed
> from a very few years ago.
Well, I think that if we look at the size of the existing software
library, we would be hard-pressed to find many computer users who are
in fact using all the software they might benefit from right now.
(Does any individual alive even *comprehend* what all that software
can do?) If the hardware speed enthusiasts want to keep the world safe
for faster hardware, then they are eventually going to have to do
something about not only the gap between hardware and software, but
between software and users.
What? Dunno. But for starters, having computers that are unable to run
major chunks of the existing software library, even inefficiently,
sounds to me like a big, big problem. (However, this is again as much
a problem amenable to new software (emulators, etc.) as it is to new
hardware (e.g., overlapping instruction sets).)
Another possible tactic is for hardware vendors to fund development of
complex, compute-intensive software, and then give it away to users
when they buy hardware. If you can successfully bundle enough software
to insure the box is choked the second it gets installed, and the
software is worth running, then you've got your repeat business right
there. That shouldn't be too hard to do; a few generous grants to the
Free Software Foundation would probably do the trick.
Dan Mocsny
dmo...@uceng.uc.edu
John R. Levine
>Another possible tactic is for hardware vendors to fund development of
>complex, compute-intensive software, and then give it away to users
>when they buy hardware. If you can successfully bundle enough software
>to insure the box is choked the second it gets installed, and the
>software is worth running, then you've got your repeat business right
Some of us remember when such programs were called "operating systems" and
they were bundled in free with the hardware. Then due to a conbination of
government action against IBM and everybody noticing that they were spending
as much on the free software as they were on the hardware, they started to
charge for the software. My experience in the software business tells me that
we software types will have no trouble pissing away whatever hardware
resources we can get our hands on, without subsidies from hardware vendors.
Mark Mendell
DbXtra 2.1 (HCR's port of BSD dbx) on 386/IX also uses the 386 debug registers
to tell when a variable has been changed (or accessed), and also to test
when a given condition becomes true. I.e. stop if i > 99
A brief (and very unbalanced test) gave me a test case where the new version
(using the debug registers) ran the test program 300 times faster than the
old method of doing this in dbx, which is to stop after every statement,
and then test the condition. I also found that the penalty for using the
debug registers at all was about 3% slowdown. This is because the LE bit must
be set in the debug control register, so that 'exact data breakpoint match'
is true, and the data breapoints are reported on the instruction that causes
them. I assume that this slows down the pipeline somewhat.
Dbxtra 2.1 for 386/IX will be available in January '90.
Does anyone know when the 386 debug registers dr4 and dr5 will be available?
The 486? 586? It would be nice to be able to span more than 16 bytes
worth of data for these breakpoints!
--
Mark Mendell, HCR Corporation
130 Bloor St. W., Suite 1001, Toronto
Phone: (416)-922-1937, Fax: (416)-922-8397
Usenet: ...!hcr!markm