🚀 go-pugleaf

In article <mwm.2n3n@contessa.palo-alto.ca.us> mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:
>In <BxpsHo.MID@mentor.cc.purdue.edu>, hrubin@mentor.cc.purdue.edu (Herman Rubin) wrote:
>> This is not a change in subject.  It is the question of whether one
>> is allowed to directly use the machine hardware, or whether one must
>> HOPE that the compiler writer considered what you are doing when the
>> compiler was produced.

>First, the people responsible for allowing you to access the hardware
>*directly* are the hardware vendors. If it's that important to you,
>you should use the facilities they provide. Better yet, convince them
>to give you a WCS, so you can access the underlying hardware, and not
>have to full with the macromachine. That can trim as much as an order
>of magnitude off your program.

So far, I have not had too much trouble in at least getting access to
the machine instructions.  But Dik Winter has just posted a followup
to one of his postings in which he stated that, on the machine he is
now using, he has no access to the assembler.

>If you don't like the syntax they provide for accessing these
>facilities, bitch at *them*. Have you called the people who build the
>machines you use and asked for a more accessible assembler?

It is not a matter of access, but of SYNTAX.  

>As for compiler writers, your hope is that what you are doing was
>important to a large enough fraction of the user base that they did
>it. As has been repeatedly pointed out, that's not the case for you
>and most popular languages.

>Clearly, you need a language designed for your purposes. This has also
>been pointed out repeatedly. People have even volunteered to take a
>first crack at writing it, if you'd provide the spec. You still
>haven't provided a spec for it.

I have repeatedly stated that it is impossible to produce a perfect
language, even for my purposes.  I have not asked for one.  

What I have asked for is that the language be fully extensible.  If
I want to add another type, I do so.  To SOME extent, C has this in
structs, and C++ does a good job with its classes.  But we should at
least call a spade a shovel, and call this typedef, and rename the
C misnomer typealias.  I know that it is bad to change existing 
terminology, but in this I am less guilty than the C creators.  
I did use typedefs on Fortran IV for the CDC 3600 in the mid 60s.

>You complain that you don't have time to write such a spec, much less
>a compiler. Yet the amount of time you've spent arguing on usenet
>would seem sufficient to write the compiler. Clearly, it's more than
>enough time to write the spec.

I still do not know what you mean by a spec.  I have stated that one
thing which is certainly going to be needed is a really versatile
macro converter.  What this is supposed to do is to convert from
one syntax to another, but taking into account that the variables
might have attributes, like types, storage classes (in particular,
register), and whatever else seems needed.  I have given examples 
of this, and I have been informed by those I respect that this can
be done.  

Looking at what I have written above, the types certainly will not be
limited to those in the current languages.  Bob Silverman has given 
some examples of the notation; he would like to write

	c = a ** b

to multiply two integers of a given size to form a double length integer.
Now in C++ one could insert a function doubmult, and even overload it to
handle the possibility of different lengths being doubled, and instruct
the compiler (?) to inline this.  Now with the macro converter, Bob would
still have to define the function doubmult, but he could also have the
macro conversion instruction

### 	a ** b	{
	doubmult(a,b);}#

or some other suitable notation, and then he could blithely write a ** b
in the program wherever he wants to.   Now there are more complicated
situations.  There is one which even others have cited as "impossible"
to understand.  I will now endeavor to show that it is not so bad, and
I will give most of what it is doing, and why.  The syntax is

	c{'z} ={tc} {-}{|}{ta} a{'x} OP{mod} {|}{tb} b{'y} {/\{~}w}
	  1     2    3  4   5     6  7   8    9  10    11   12 13

Since there are so many optional fields, I have numbered them.  Now this
is what it requires:

	c must be a register holding a vector descriptor.  The type of 
	the vector may be integer or float or ..., and also half or full.

	If field 1 is present, c must be an even numbered register, and
	the integer z must be in the next register.  The c (and w) offset
	bit in the instruction is set; otherwise it is cleared.

	If field 2 is present, the half/full type of c is overridden.  
	this bit in the instruction is set iff the final type is half, 

	If field 3 is set, the first argument is negated.  

	If field 4 or 9 is set, the modulus of the argument is used.

	a and b are either vector descriptors in registers, or scalars
	in registers.  Fields 5 and 10 cause the appropriate bits in the
	instruction to be set if scalars are used.

	If a or b is a vector, it can be offset.  Fields 6 and 11 cause
	the register addresses of the offsets to be inserted in the
	instruction.  Otherwise 0 must be used.

	Field 12 specifies that a control vector is used.  In that 
	case, the bit address of the start of the control vector 
	must be in the register address in the instruction.  The
	z offset, if present, is used.

	Field 13 specifies that the control vector is toggled, which
	means that 0 enables the operation rather than 1.

	Field 7 specifies the operation (+ - * / sqrt etc.)  I will
	list the defaults and options for + only.  If the type of c
	is integer, the default is upper.  If it is float, the 
	default is normalize.  If it is address, the default is 
	"address".  The possiblilities are upper, lower, normalize,
	and address, and field 8 allows the default to be changed.

>Let me suggest that next quarter, when whatever regular event it is
>that triggers your posting to usenet happens, instead of sitting down
>and baiting newbies, why don't you sit down and start the spec for the
>language you want to be using? Post *that* instead of the usual
>harangue. If people are as wrong as you say they are, it should be
>immediately obvious that the product is far superior to all other
>languages. If that isn't the case, you will probably get some feedback
>from people who have experience at language design/implementation,
>pointing at what will be hard to do, and what would be a useful
>addition to other languages.

>> Are we going to allow the driver to use the steering wheel and the 
>> accelerator and brake, or just have a program to run the car?

>When the technology gets there, the user is going to have a program.
>Circumventing it will be a crime. That's because the kind of silly
>mistakes you get from going directly to the hardware in a car kill
>people, not programs.

This statement does not surprise me.  As Franklin stated, quote from memory

	Those who will give up essential liberty for little safety 
	deserve neither liberty nor safety.

>> One major advantage of Arabic over Roman is that Arabic can usually
>> be written faster.  Are reference notations anywhere near as fast as
>> pointers?

>They can be written faster, because they are closer to the problem.
>They allow the compiler more latitude in implementation, meaning that
>the *worst case* is that they run as slow as pointers, and in many
>cases can use faster implementations, so they run faster. In other
>words, they are a win-win solution.

I do not see how any system of references will enable writing

	*fill(*descriptor)

any faster.  Nor do I trust compiler writers (or government bureaucrats.)
And if the lack of pointers in the languages causes hardware to elide pointers
in favor of something clumsy like call_by_name, searching the name file, we
all lose.  I have also pointed out that I want to use this in cases in which
the calling routine does not even know the name.  True, you could read the
name, but is that any easier than reading the address?
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)