Path: utzoo!mnetor!uunet!husc6!uwvax!dogie!uwmcsd1!marque!gryphon!edk
From: edk@gryphon.CTS.COM (Ed Kaulakis)
Newsgroups: comp.arch
Subject: Re: Was: RISC is a nasty no-no! More to the point: Supercomputer addresses
Message-ID: <2869@gryphon.CTS.COM>
Date: 13 Mar 88 20:05:19 GMT
References: <179@wsccs.UUCP: <696@nuchat.UUCP: <284@scdpyr.UUCP> <24861@yale-celray.yale.UUCP>
Organization: Trailing Edge Technology, Redondo Beach, Ca.
Lines: 26
Summary: my buggywhip should drive design forever...

In article <24861@yale-celray.yale.UUCP>, leichter@yale.UUCP (Jerry Leichter) writes:
> In article <24737@yale-celray.yale.UUCP> lisper@yale-celray.UUCP (Bjorn Lisper) writes:
[]
> Nice theoretical argument - but it ignores the central issue:  Maybe the
> REASON the scientific community like FORTRAN is that it ALLOWS them to "play
> around".  In fact, such "playing around" is an absolutely standard technique
> in many large numerical codes; it's what makes them practical.  A common thing
> to do is to allocate a large one-dimensional array and carve variable-sized
> 2-D arrays out of it.  The way this is done is ugly, because FORTRAN has no
> inherent ability to deal with dynamic memory allocation so it all has to be
> faked.  If the code had been done in C, for example, the space would have been
> allocated with malloc().  Of course, that doesn't really give the a compiler
> much more to go on than was available in the FORTRAN case!
> 
> Before proposing to remove something so central to large codes, you'd better
> understand WHY it's central, and what you can provide to replace it with.
> 
> 							-- Jerry


	Therefore, it's not worth discussing other approaches? 

	Look, I know how you feel. Read "Time, Progress, and the Older 
	Programmer". The only substitute for 30 years experience is 5
	years experience, 6 times.  It will be time to retire soon anyway.
	Take your pills.