HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.lang.misc
From: tlai@cs.toronto.edu (Tony Wen Hsun Lai)
Subject: Re: Accessing the hardware directly (Was: Pointers)
Organization: Department of Computer Science, University of Toronto
Date: 16 Nov 92 03:09:02 GMT

In article <BxsCMz.Mu1@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:
>What is my notation other than calling the function by an indirect reference,
>and passing the argument similarly?  Now I can put the argument reference on
>the stack by first reading it into a register and then putting that register
>on the stack, but what is gained by that?  And if the machine does not have
>a reasonable way to call a function by indirect reference, the only way that
>it could be done is by placing the address in the code for the function call
>at run time, and this, or any other, modification of code at run time is,
>I believe, considered quite objectionable.

Just out of curiosity, what do you think a procedure type is?

In a language like Modula-3, conceptually, a procedure declaration is a
declaration of a constant of the appropriate procedure type, and one can
pass procedures as parameters, store procedures in variables, invoke
procedures stored in variables, and the like.  A compiler will probably
implement all this with pointers, but you don't have to explicitly
dereference pointers yourself, just as you don't have to explicitly
dereference pointers when passing arguments by reference in Pascal or
FORTRAN.  Do you really like typing so many "&"'s and "*"'s in C?
Newsgroups: comp.lang.misc
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: languages which allow the introduction of new operators
Organization: Purdue University Statistics Department
Date: Sun, 22 Nov 1992 13:54:08 GMT

In article <722322705@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:

			...................

                  e can communicate binary integers across machines
>: and implementations; the much used notation 0ddddd for octal and
>: 0xdddddddd for hexadecimal, bad as they are, do this explicitly.
>
>So, what does this have to do with the semantic model of the language?
>What prevents one from converting the floats to binary representation
>in ascii, transmitting that, reading the result, and doing the
>inverse conversion?

This will not do the job.   The binary representations of floats on
CRAYs, CYBERs, VAXen, RS/6000s, etc., are all different.  Also, these
are only the representations of floats within the precision of the
machine.  In addition, there is NO remotely standard fixed-point 
binary representation of non-integers which can be communicated.

With integers, we can transmit integers of arbitrary length in decimal,
octal, or hexadecimal without having any idea of how the hardware/software
of the machine handles it.  We have corresponding facilities for fixed-
point and floating-point decimals.  If someone types in pi to 200 digits,
there is no problem in understanding what is communicated, whether fixed-point
or floating-point.  But now how do you do this if one is not interested in
communicating the decimal representation, but the hex or octal?  

If one is writing a program, the non-integral constants often should be
given in octal or hex for various reasons.  This means that the language
in which that program is written must have some way to read them.
-- 
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)
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.misc
Subject: Re: Pointers
Date: 13 Nov 92 09:43:29 GMT
	<BxLyv1.CG4@mentor.cc.purdue.edu>
Organization: Department of Computer Science, University of Manchester
In-reply-to: hrubin@pop.stat.purdue.edu's message of 12 Nov 92 14:57:00 GMT

In article <BxLyv1.CG4@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
   >You might claim that "reference" (or "ref") is just "pointer" spelled
   >sideways, but there is no "address of" operation, no "indirect"
   >operation, and hence no EXPLICIT pointer operations at all in the
   >language.

   But how does the hardware do it efficiently?

Who cares, as long as it does?

   Probably with pointers, because the hardware only calls by reference.

So what?  If the compiler does the correct and most efficient thing,
why should I care how it does it.  If the quality of the compiler is a
problem, get another one.  If that doesn't work, write in assembler.
If the syntax isn't all that great, use a macro processor to create
hide some of the worst parts.  Note this is not an invitation to
complain that you can't find a macro processor that will let you
invent your own syntax.

bevan
Newsgroups: comp.lang.misc
From: tlai@cs.toronto.edu (Tony Wen Hsun Lai)
Subject: Re: Accessing the hardware directly (Was: Pointers)
Organization: Department of Computer Science, University of Toronto
Date: 16 Nov 92 00:54:41 GMT

In article <BxrK6x.A04@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
[stuff deleted]
>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?

I guess you don't like pass by reference?  Pass by reference is almost
inevitably implemented using pointers, but doesn't involve _explicit_
pointers set up by the programmer.  You may not need or appreciate
abstractions for your programming, but if you look at the evolution of
language design, abstractions are important for designing and writing very
large, maintainable programs.
Newsgroups: comp.lang.misc
From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
Subject: Pointers
Organization: Purdue University Statistics Department
Date: Wed, 18 Nov 1992 01:07:45 GMT

In article <waterman.722038647@chaos.cs.brandeis.edu> waterman@cs.brandeis.edu writes:

			............................

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

>>	*fill(*descriptor)

>>any faster. 

>How about
>	fill(descriptor)  ?

>Remeber, the dereferencing of the names 'fill' and 'descriptor'
>are done only once, at _compile_ time, and don't take up a single
>iota of energy at _run_ time.

"This does not compute."  The module which produces the contents of
fill and descriptor is compiled separately from the one that calls it.
In addition, I specified that there may even be run-time changes, which
the calling module does not know.  
-- 
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)
Newsgroups: comp.lang.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: Indirection
Organization: Xenix Support, FICC
Date: Fri, 20 Nov 1992 18:14:41 GMT

In article <Bxyut0.Jo@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
> In article <id.GT2V.7OE@ferranti.com> peter@ferranti.com (peter da silva) writes:
> >Personally, I think that making indirection a prefix operator was a bigger
> >mistake than any of these.

> Certainly not from the standpoint of English speakers.

Hackercentrism you us of accuse you Anglocentrism of guilty are but.

IF YOU-WANT A-PROGRAMMING-LANGUAGE DESIGNED-FOR-ENGLISH YOU-KNOW
   WHERE-TO-GET-IT.
MODIFY HERMAN-RUBIN TO PROCEED TO COBOL.

> As I understand it,
> *x in C denotes the object referred to by x, the object "found" AT x.  Thus,
> @x would have been at least a somewhat logical notation, at least relatively
> easily understood by users, as well as easy for parsing, etc.

Yes, but it makes for extra silly syntax (postfix indirection obviates the
need for ->), and makes expressions that use other indirection operators
(which are all postfix: [] and ()) much more complex:

	a = *((*f)()->baz[0]);
Instead of:
	a = f@()@.baz[0]@;
or my preferred:
	a = f^()^.baz[0]^;

I agree that C uses too many symbols, by the way. AND, OR, NOT, XOR, DIV,
and MOD make more sense in many ways. I would not want to use /\ and \/
unless you changed the escape character. I detest BEGIN and END.
-- 
Peter da Silva / 77487-5012 USA / +1 713 274 5180
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?
Newsgroups: comp.lang.misc
From: ian@syacus.acus.oz.au (Ian Joyner)
Subject: Re: Pointers
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Thu, 19 Nov 1992 12:45:33 GMT

ian@syacus.acus.oz.au (Ian Joyner) writes:
>(The B5000 also had one of the first commercial implementations of
>virtual memory, 10 years before IBM invented it!).

Well I was naturally picked up for being over brief here. I was not meaning
to imply that Burroughs had invented virtual memory, just that they had
a commercially available product 10 years before IBM's first virtual
machine.

In fact the pioneers were at Manchester University who built the Atlas
computer.  I have a description of how this technology was directly
transferred from the Atlas to the B5000.  This is an excerpt from August
1977 Creative Computing, a letter to the editor from Bill Lonergan who
was then a Principal at Xerox, but who was Manager of the Burroughs
Product Planning Group Jan 1959 to April 1961.  He was writing to set
the record straight on an article by David Bulman on stack computers:

"Virual memory: In May 1960 UCLA conducted a two week seminar entitled,
"Using and Exploiting Giant Computers." The program covered the IBM
STRETCH computer, the Univac LARC, the Ferranti ATLAS 1 and Orion
computers, the Bendix g-20, and a few other machines. The list of
attendess shows that 14 people attended from IBM and seven from Univac.
We sent Paul King and two others from Burroughs. Paul and I have often
mused that the 14 people from IBM were so wrapped up in STRETCH that
they failed to grasp the significance of what the late Stan Gill was
saying about the virtual memory organizations of the ATLAS 1. Paul
King did understand its significance and returned to Pasadena greatly
excited about the concept. After a relatively brief period of review
and discussion about how best to incorporate it, a segmented virtual
memory was defined into the B5000 system (its project name in Product 
Planning at the time was the 4000 system). The credit for the first
use of a virtual memory in a U.S. machine clearly lies with Paul King
not Bob Barton.

"(It is worth noting at this point that the conceptual notion of a
virtual machine had by this time already been a topic of much discussion
around the Burroughs Pasadena facility. I believe the notion originated
with Ted Glaser earlier in the 1950s. Ted was in the Pasadena engineering
group from 1956 to mid-1959.)

"Several other B5000 design features can be traced to the May 1960 UCLA
seminar. The idea of separate, modular input-output controllers can be
traced to the LARC and the single number form can be traced to the G-20."

-- 
Ian Joyner  ACUS (Australian Centre for Unisys Software)    ian@syacus.acus.oz
"Where is the man with all the great directions?...You can't imagine it,
 how hard it is to grow, Can you imagine the order of the universe?" ABWH
Disclaimer:Opinions and comments are personal.
Newsgroups: comp.lang.misc
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Pointers
Organization: Computer Science, University of Melbourne, Australia
Date: Sat, 21 Nov 1992 03:45:48 GMT

sakkinen@jyu.fi (Markku Sakkinen) writes:

>In article <1dujcuINNru4@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>> ...
>>C's function pointers are almost exactly like the procedure variables that
>>many other languages have.  
[...]
>>You can't cast between them and non-function pointers.
>
>In K&R C you could (char*), and in C++ you can (void*).

This is neither standard-conforming nor portable.
For example, data pointers may be 16 bits while function pointers are 32
bits (as is the case with certain memory models for DOS C compilers).

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: jlg@cochiti.lanl.gov (J. Giles)
Newsgroups: comp.lang.misc
Subject: Re: languages which allow the introduction of new operators
Date: 18 Nov 92 22:43:54 GMT
Organization: Los Alamos National Laboratory

In article <1992Nov18.154754.1848@udel.edu>, carroll@dori.cis.udel.edu (Mark C. Carroll) writes:
|> [...]
|> Optimization is a _very_ difficult business. Any optimization has
|> interactions with other optimizations, in terribly complex (and not
|> necessarily well-understood) ways. Making any change to the
|> optimization process can have broad affects on the entire process.
|> [...]

Yes.  Consider, for example, the last three things done by the 
compiler: 1) instruction selection; 2) register allocation; and
3) instruction scheduling.  On a CISC machine, this could be *very*
difficult.  For example, a memory/memory instruction doesn't
need any registers, but may alter the optimal instruction order,
which alters the optimal register allocation, which may mean that
you should now use a register/memory instruction instead.  Each
of these three parts of compilation feed-back into the other two
in compilicated ways.  (This is one of the reasons that CISC
machines are harder to write compilers for than RISC machines
are.)

|> Any optimization, particularly on modern architectures, has got to
|> consider its affect on pipeline fills, branch predictions, register
|> allocations, memory and cache uses, and dozens of other factors.  Do
|> you think that you're qualified to judge what affect your two-cycle
|> savings will have on the rest of your program? If so, you're in the
|> wrong field - you should be designing compilers.

To be fair to Dr. Rubin, he wants to be able to specify information
that the high-level language cannot directly represent.  In particular, 
many high level languages don't have the capability to directly express 
operations that modern machines can do.  In these instances, the machine's 
assembly language is higher-level than the so-called high-level language 
you're compiling from.  You need to be able to tell the compiler what to 
do.  For example, on vector machines there are often vector merges based 
on the vector mask - but C doesn't have a way to directly instruct that 
a given integer be stored into (or read from) the vector mask!  Coding 
around this in C would require that you rely on the compiler being able 
to *infer* from some standard C construct that the vector mask is what 
you're after.  Most compilers aren't up to it.  But, if you could just
say: "use the vector mask", the code would, very likely, run much
faster.

-- 
J. Giles
Newsgroups: comp.lang.misc
From: ian@syacus.acus.oz.au (Ian Joyner)
Subject: Re: Pointers
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Tue, 17 Nov 1992 12:15:28 GMT

mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:

>I do agree that any language designed to be close to that class of
>hardware would look pretty much like C. After all, the features and
>constructs are dictated by the hardware, not the language designer.
>About all that's left is syntax. Sure, there are lots of places C
>could be improved, but they wouldn't lead to a radically better
>language, just one that was easier to read, without quite so many
>gotchas.

I was in a bookshop the other day, and was browsing through Tannenbaum's
book on Operating Systems. I was interested in his remarks on the design
of some early computers around the late 50s, early 60s. He said of the
Burroughs B5000 (ancestor of Unisys A Series desktop/mini/mainframe range),
that it was primarily designed by considering the software first. From
the beginning, it was designed to have all systems software written in Algol,
(which it still does, or Algol derivatives, such as NEWP, Pascal, etc).
(The B5000 also had one of the first commercial implementations of
virtual memory, 10 years before IBM invented it!).

His main point was that this was a successful attempt at developing a
machine by considering the software first, not the hardware, but as
soon as it was shown that this was possible, it was quickly forgotten.

Well, I won't forget it. It is the purpose of computer hardware to run
software. It is not the purpose of software to be crippled by the
compromises and limitations of current generation hardware.

So hardware design must be dictated by software considerations, not
vice versa, as is so apparent in languages like C.
-- 
Ian Joyner  ACUS (Australian Centre for Unisys Software)    ian@syacus.acus.oz
"Where is the man with all the great directions?...You can't imagine it,
 how hard it is to grow, Can you imagine the order of the universe?" ABWH
Disclaimer:Opinions and comments are personal.
Newsgroups: comp.lang.misc
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Organization: Purdue University Statistics Department
Date: Tue, 17 Nov 1992 22:10:30 GMT

In article <KERS.92Nov17090305@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:
>I've (tried to) direct followups away from comp.arch.

>In article ... tmb@arolla.idiap.ch (Thomas M. Breuel) writes:

>   The problem is that user-defined operators cause problems about which
>   the compiler cannot warn reliably. For the rationale and some examples
>   of what can go wrong, see the ARM, p331.

>It says ``This extension, however, would imply a significant extension of
>complexity of syntax analysis and an uncertain gain in readability.'' It then
>remarks that precedence and associativity must either be fixed for all
>user-defined operators, or a mechanism must be present to define them; it is
>this latter that is the tricky point. (The ``complexity of syntax analysis''
>argument seems to be terribly weak, given that (a) Stroustrup is not stupid,
>and (b) the rest of C++.)

>There are many other things compilers cannot warn about reliably, or indeed, at
>all; writing ``-'' when one meant ``+'', forgetting to increment a counter,
>calling the wrong function (or not calling the right one), writing ``0'' when
>style demands FALSE or NULL_String, and so on. Has anyone done some *research*
>on the issue, rather than making *-informed speculation?

>[My own speculation is that it's all perfectly sensible provided you're
>prepared to forgo the ability to define your own precedence and associativity,
>and that operator tokens are recognisable by spelling just as identifiers are.
>What would be handy, I think, is a way of making *any* dyadic function into an
>infix with a simple syntactic mark, eg, ``E1 @F E2''.]

The precedence problem was actually aggravated by C, and I suspect that it
is necessary to do some pulling back.  The user who has not run into the
specific situation is likely to get a rather large number of the precedences
wrong.  What is the correct association in a << b + c?  Everyone I showed 
this to came up with the same answer; but that answer is wrong in C!  One
cannot even get the compiler to consider spacing in resolving this.  I 
would just as soon go the the APL idea, which only distinguishers unary
and binary.  It would help if we could get a more complicated set of 
parentheses, or allow explicit temporaries to be used to break up the
operation stream; this would certainly be needed if functions produced
a list of results.

I agree that this complexity of syntax analysis is very weak.  Put one
precedence for unary operators and another for binary operators, or even
equate the infix notation x FOO y with !FOO(x,y); those of us who want 
to use user-defined operators would find this a lot preferable to not
allowing them at all, even if we had to use parentheses all the time.
-- 
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)
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.misc
Subject: Re: Pointers
Date: 21 Nov 92 16:30:11 GMT
	<BEVAN.92Nov14094620@tiger.cs.man.ac.uk> <id.WT4V.FC2@ferranti.com>
Organization: Department of Computer Science, University of Manchester
In-reply-to: peter@ferranti.com's message of 20 Nov 92 17:57:48 GMT

In article <id.WT4V.FC2@ferranti.com> peter@ferranti.com (peter da silva) writes:
   In article <BEVAN.92Nov14094620@tiger.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
   >    The only language that I would imagine might be a serious alternative
   >    to C among those that you have listed is Modula-2, but I'm not
   >    sufficiently familiar with its low-level features to say whether it
   >    could cover the same breadth of system-programming problems that C
   >    covers.

I didn't write the above.

   > Name the problems and we can find out.

[ This I did write ]

   Complete lack of anything like a standard runtime library. Not even all
   compilers provide the InOut library specified in Wirth, and those that
   do all end up having custom extensions for stuff I can do using stdio
   in C.

I agree the IO was a mess.  It has now been fixed (well almost :-),
but years too late.   IMHO Modula II is a classic example of how not
to go about standardising an existing language, though I should note
that the end product has merit.  I see parallels in the current C++
standardisation effort (have they decided on a string class yet?),
with the difference that I'm skeptical about any merit in the product :-) 

bevan
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.misc
Subject: Re: Pointers
Date: 16 Nov 92 16:39:36 GMT
	<1992Nov10.024021.8724@linus.mitre.org>
	<BEVAN.92Nov11191720@beluga.cs.man.ac.uk> <Bxq1C2.1CC@fiu.edu>
Organization: Department of Computer Science, University of Manchester
In-reply-to: feathers@serss0's message of 14 Nov 92 19:40:49 GMT

In article <Bxq1C2.1CC@fiu.edu> feathers@serss0 (Michael Feathers) writes:
   [ nearly all the article because I essentially agree with it ]

   Ada, Eiffel, El(Alpha), and Turing are all great for their
   application domains but I think that they are subsets of C and
   C++'s application domains.  

If the implication is that C and C++ are the lowest common denominator
amongst the above, then the statement is obviously true (though I'd
argue about El(Alpha)).  However, (almost) by implication this also
means there is something "better" than the lowest common denominator
for the required task.  If all you have is a hammer ...?

bevan