Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.lang.misc Subject: Re: Efficient Fortran Message-ID: Date: 4 Aug 90 19:26:48 GMT References: <1991@key.COM> <2378@l.cc.purdue.edu> <8E+4_83@ggpc2.ferranti.com> <2426@l.cc.purdue.edu> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 42 Herman Rubin: "You're denying the artisan his tools". Me: "Oh, garbage. If you're writing non-portable code anyway use assembly. Or... have you considered Forth?" In article <2426@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) follows up with a complete non-sequiter: > I have never objected to having semi-portable code. So why don't you write this code the same way everyone else does: by implementing it in a high level language and then modifying the algorithm and recoding parts of it in assembly. > Forth is also clumsy and inefficient. An intelligently written assembler, > which allowed overloaded operators and weak typing, would be useful, Forth *is* an intelligently-written assembler, for an ideal stack-based computer. Most production Forth code also includes high level assembly code for the actual underlying hardware. You're welcome to write your whole program that way if it suits you. [the following gibberish] > c{'z} ={tc} {-}{|}{ta}a{'x} OP{mod} {|}{tb}b{'y} {/\{~}w} > is the way I would write the general vector instruction on the CYBER 205. > with braces enclosing optional fields. If you explain what that means, I'll attempt to write it in Forth assembler. I'm sure it would be more readable. You've actually come up with something less readable than naive Forth. Be proud. > I have not run into anything which can not be written in a semi-portable > manner. So now who is it that is denying the artisan his tools? Herman, I really think you'd like Chuck Moore. -- Peter da Silva. `-_-' +1 713 274 5180. 'U`