Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!rpi!batcomputer!cornell!uw-beaver!ubc-cs!alberta!mts.ucs.UAlberta.CA!vm.ucs.ualberta.ca!ECULHAM
From: ECULHAM@vm.ucs.UAlberta.CA (Earl Culham)
Newsgroups: comp.arch
Subject: Re: VLIW Architecture
Message-ID: <721@vm.ucs.UAlberta.CA>
Date: 6 Oct 89 16:02:19 GMT
References: <251FCB3F.12366@maccs.dcss.mcmaster.ca> <1050@m3.mfci.UUCP> <13050@pur-ee.UUCP> <1630@l.cc.purdue.edu>
Reply-To: ECULHAM@vm.ucs.UAlberta.CA
Organization: University of Alberta VM/CMS
Lines: 26
Disclaimer: Author bears full responsibility for contents of this article

In article <1630@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes:
 
 .... all sort of things about languages accessing the hardware
      through computer languages
 
This is an open letter to Herman Rubin.
========================================================================
Rubin, I realise that what you are trying to say in your postings is
  "Don't throw away the power of the computer by limiting yourself to
   high level languages."
But, you are going overboard when you say that NO language is designed
for the effecient use of hardware operations. I can name two right off,
Assembler, and PL360.
 
We have a dichotomy between wanting a program to run as fast as possible
on our current machine, and wanting it to keep running as we migrate
to new machines.
 
Often, your comments are along the line
  "We need access to the nitty-gritty in order make this algorithm fly."
Nice ideas, but they don't belong in comp.arch. Please take them to
a language discussion.
 
On the other hand, comments along the lines of
  "Having feature 'x' in hardware would sure make algorithm 'y' run fast"
are welcome grist.