🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #1446

Re: Efficient Fortran

#1446
From: Richard A. O'Keefe
Date: Mon, 06 Aug 1990 06:38
71 lines
3082 bytes
There's a rather interesting idea I picked up from Burroughs.
They had this really neat way of producing assembly code for the
Datacom Processor (a little parasite that sat inside a B6700 and
did network stuff).  Your assembly code program was a program
written in Algol.  Imagine something like an M680x0.  You might do

	movl(d0, offset(a0,20));	% [a0+20] := d0

Here the arguments to movl were expressions which constructed trees.
So you could also do things like

	myvar := offset(a0,20);		% myvar .equ [a0+20]
	movl(myvar, d0);		% d0 := [a0+20]
	clrl(myvar);			% [a0+20] := 0

The scheme was a two-pass one.  The top level program had the form

	begin
	    integer pass;
	    <declare all the "opcodes" and tree builders>
	    procedure user_program;
		begin
		    <"macros" become ordinary procedures>
		    <instructions become procedure calls>
		end;

	    pass := 1;
	    user_program;
	    pass := 2;
	    user_program;
	    save_virtual_store(outputfile);
	end.

With a scheme like that, one might handle Rubin's example thus:

> > 	c{'z} ={tc} {-}{|}{ta}a{'x} OP{mod} {|}{tb}b{'y} {/\{~}w}

1.  An operand is an address, perhaps with a type.  So we might use
	myvec		for a simple address
	SINGLE(myvec)	for a typed address

2.  A source operand is
	<operand>	use operand
    or	-<operand>	use NEG(operand)
    or	|<operand>	use ABS(operand)
    or	-|<operand>	use NEG(ABS(operand))

3.  I've forgotten what {mod} and {/\{~}w} are, I think w has to do
    with masking.  So let's assume
	vecop(Dest, Src1, Op, Src2)		-- mask omitted
	vecmask(Dest, Src1, Op, Src2, Mask)	-- mask required
    e.g.
	vecmask(INT(out), ABS(SINGLE(in1)), GTR, ABS(SINGLE(in2)), NOT(mask));
    instead of
	out int = |in1 single > |in2 single /\~mask

I've written "assembly code" this way using Algol, Pop, Lisp, and Prolog
as the actual source languages.  Works like a charm, and you have *really*
nice languages for writing your "macros"...  The syntax isn't assembly-like,
and it isn't all that much like what Herman Rubin wants, but a small dose
of Stage 2 will fix that.  (Anyone remember Stage 2?  Anyone remember Wisp?)

Doing a really thorough job of this kind of thing requires a sort of
macro facility where the macro language can ask about types and attributes
of the arguments.  Something not altogether unlike Ada might actually make
a good basis for this.

-- 
Distinguishing between a work written in Hebrew and one written in Aramaic
when we have only a Latin version made from a Greek translation is not easy.
(D.J.Harrington, discussing pseudo-Philo)
Technical Details
Message-ID: <3521@goanna.cs.rmit.oz.au>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!munnari.oz.au!goanna!ok
References: <1991@key.COM> <2378@l.cc.purdue.edu> <ARS4N0F@xds13.ferranti.com> <Z1=48:5@ggpc2.ferranti.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.misc
Subject: Re: Efficient Fortran
Message-ID: <3521@goanna.cs.rmit.oz.au>
Date: 6 Aug 90 06:38:37 GMT
References: <1991@key.COM> <2378@l.cc.purdue.edu> <ARS4N0F@xds13.ferranti.com> <Z1=48:5@ggpc2.ferranti.com>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 71