Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin From: hrubin@pop.stat.purdue.edu (Herman Rubin) Newsgroups: comp.arch Subject: Re: Computers for users not programmers Summary: With the hardware of that time, ... Message-ID: <6048@mentor.cc.purdue.edu> Date: 16 Feb 91 13:12:07 GMT References: Sender: news@mentor.cc.purdue.edu Lines: 30 In article , mccalpin@perelandra.cms.udel.edu (John D. McCalpin) writes: > >On 15 Feb 91 15:19:10 GMT, mcdonald@aries.scs.uiuc.edu (Doug McDonald) said: > > Doug> In article > khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) writes: ........................ > This was one of the points that was addressed in the Algol-68 concept > of standard packages. The idea was that several commonly used modules > would be standardized as part of the language. They could be defined > in terms of the language, which would provided instant portability, > but might also suffer in performance (as McDonald points out above). The hardware of that time had major differences from that of today. One of them was that for most of the machines of the time, transfers were the fast operations, and memory access next, while arithmetic was relatively slow. People were still counting multiplication/divisions as the cost of computing, and largely ignoring memory/register considerations. The B5500 was designed as an Algol machine, and had a stack, but essentially no registers. Inlining did not pay much. Times have changed. On the mainframes I am familiar with, context switch, and even subroutine call/return, are costly. Instruction memory is rarely a problem. Implementing a hardware operation in software can multiply the cost by 10 or more. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)