Peter Flass wrote:
> Quadibloc wrote:
>> On Mar 5, 3:54 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
>>> Quadibloc wrote:
>>>> On Feb 22, 3:53 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
>>>>> PL/I can be, but doesn't have to be.  If the arguments of a
procedure
>>>>> match the parameters, only the argument address (and possibly a
>>>>> descriptor address for strings structures, and arrays) is passed.
>>>> Doesn't PL/I (or, rather, normal implementations thereof) support
>>>> separate compilation of subroutines, just like FORTRAN and COBOL?
>>> Yes, but the calling sequence among PL/I programs passes information on
>>> string  lengths, array bounds,
>>
>> which is why the "bloat" is unavoidable in PL/I, not unnecessary, you
>> had previously claimed and as I was trying to contradict. Yes, I'm
>> well aware PL/I does not use the standard S-type calling sequence.
>>
> 
> 
> Yes, but is it bloat?  When I've converted C functions that work with 
> arrays, most of them need to be passed the [address of the] array and 
> the upper bound.  The first thing I do is get rid of the latter, since 
> it's handled automatically, but it's necessary one way or the other, so 
> why not have the language do it?

Sorry to reply to my own post, but I just thought of something I should 
have said.  If you want to eliminate all the "bloat" and emulate C 
directly in PL/I, it's possible.

   DECLARE my_array (0:some_upper_bound-1) ...attributes... ;
   /* By default, PL/I arrays start with subscript one,
    * to exactly duplicate C change the lower bound to zero.
    * Also, C arrays are declared with [number_of_elements] rather
    * than highest subscript.  Since the lower bound is zero
    * the number of elements is always one greater than the highest
    * subscript, which is always a source of confusion
    * for new C programmers.
    */
   DECLARE my_C_func ENTRY(POINTER, FIXED BINARY) OPTIONS(..options...);
   /* The "OPTIONS" keyword would indicate that this function is
    * a C or C-like function.  For IBM this is "BYVALUE LINKAGE(SYSTEM)".
    */
   CALL my_C_func( addr(my_array), some_upper_bound );
   /* This calls the function exactly as in C, passing the address
    * of the array and the upper bound by value
    */

Now try to replicate PL/I calls in C.

In article
<2...@eircom.net>,
 Ahem A Rivet's Shot <s...@eircom.net> wrote:

> On Fri, 5 Mar 2010 09:07:31 -0800 (PST)
> Quadibloc <j...@ecn.ab.ca> wrote:
> 
> > On Feb 26, 4:56 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> > 
> > >         No, he's saying that C doesn't really implement an array type,
> > > the var[offset] syntax is just syntactic sugar for *(var + offset)
> > > which is why things like 3[x] work the same as x[3] in C.
> > 
> > Um, no.
> > 
> > x = y + 3 ;
> > 
> > in a C program will _not_ store in x the value of y plus the contents
> > of memory location 3.
> 
> 	No but x = *(y + 3) will store in x the contents of the memory
> location at 3 + the value of y just as x = y[3] will and x = 3[y] will,
> which is what I stated. You missed out the all important * and ()s.

No, that will compare x and the right val.

= is a comparasion operator in c.

-- 
 A computer without Microsoft is like a chocolate cake without mustard.

In article
<p...@news.panix.com>,
Walter Bushell  <p...@panix.com> wrote:
>In article <2...@eircom.net>,
> Ahem A Rivet's Shot <s...@eircom.net> wrote:
>
>> On Fri, 5 Mar 2010 09:07:31 -0800 (PST)
>> Quadibloc <j...@ecn.ab.ca> wrote:
>> 
>> > On Feb 26, 4:56 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>> > 
>> > >         No, he's saying that C doesn't really implement an array
type,
>> > > the var[offset] syntax is just syntactic sugar for *(var + offset)
>> > > which is why things like 3[x] work the same as x[3] in C.
>> > 
>> > Um, no.
>> > 
>> > x = y + 3 ;
>> > 
>> > in a C program will _not_ store in x the value of y plus the contents
>> > of memory location 3.
>> 
>> 	No but x = *(y + 3) will store in x the contents of the memory
>> location at 3 + the value of y just as x = y[3] will and x = 3[y] will,
>> which is what I stated. You missed out the all important * and ()s.
>
> No, that will compare x and the right val.
>
> = is a comparasion operator in c.

No it isn't.  '=' is assignment; '==' is comparison.

Walter Bushell <p...@panix.com> writes:

> In article <2...@eircom.net>,
>  Ahem A Rivet's Shot <s...@eircom.net> wrote:
> 
> > On Fri, 5 Mar 2010 09:07:31 -0800 (PST)
> > Quadibloc <j...@ecn.ab.ca> wrote:
> > 
> > > On Feb 26, 4:56 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> > > 
> > > >         No, he's saying that C doesn't really implement an array
type,
> > > > the var[offset] syntax is just syntactic sugar for *(var + offset)
> > > > which is why things like 3[x] work the same as x[3] in C.
> > > 
> > > Um, no.
> > > 
> > > x = y + 3 ;
> > > 
> > > in a C program will _not_ store in x the value of y plus the contents
> > > of memory location 3.
> > 
> > 	No but x = *(y + 3) will store in x the contents of the memory
> > location at 3 + the value of y just as x = y[3] will and x = 3[y] will,
> > which is what I stated. You missed out the all important * and ()s.
> 
> No, that will compare x and the right val.
> 
> = is a comparasion operator in c.

I think you've got them mixed up.  = is the assignment operator, == is
the comparison operator.

-- Patrick

Walter Bushell <p...@panix.com> writes:

> In article <2...@eircom.net>,
>  Ahem A Rivet's Shot <s...@eircom.net> wrote:
>
>> On Fri, 5 Mar 2010 09:07:31 -0800 (PST)
>> Quadibloc <j...@ecn.ab.ca> wrote:
>> 
>> > On Feb 26, 4:56 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>> > 
>> > >         No, he's saying that C doesn't really implement an array
type,
>> > > the var[offset] syntax is just syntactic sugar for *(var + offset)
>> > > which is why things like 3[x] work the same as x[3] in C.
>> > 
>> > Um, no.
>> > 
>> > x = y + 3 ;
>> > 
>> > in a C program will _not_ store in x the value of y plus the contents
>> > of memory location 3.
>> 
>> 	No but x = *(y + 3) will store in x the contents of the memory
>> location at 3 + the value of y just as x = y[3] will and x = 3[y] will,
>> which is what I stated. You missed out the all important * and ()s.
>
> No, that will compare x and the right val.
>
> = is a comparasion operator in c.

Umm..... no.  It's not.  It's the assignment operator.
-- 
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)

Walter Bushell wrote:
> In article <2...@eircom.net>,
>  Ahem A Rivet's Shot <s...@eircom.net> wrote:
> 
>> On Fri, 5 Mar 2010 09:07:31 -0800 (PST)
>> Quadibloc <j...@ecn.ab.ca> wrote:
>>
>>> On Feb 26, 4:56Â am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>>>
>>>> Â  Â  Â  Â  No, he's saying that C doesn't really implement an array
type,
>>>> the var[offset] syntax is just syntactic sugar for *(var + offset)
>>>> which is why things like 3[x] work the same as x[3] in C.
>>> Um, no.
>>>
>>> x = y + 3 ;
>>>
>>> in a C program will _not_ store in x the value of y plus the contents
>>> of memory location 3.
>> 	No but x = *(y + 3) will store in x the contents of the memory
>> location at 3 + the value of y just as x = y[3] will and x = 3[y] will,
>> which is what I stated. You missed out the all important * and ()s.
> 
> No, that will compare x and the right val.
> 
> = is a comparasion operator in c.
> 

'=' is assignment, '==' is comparison.

On Mar 4, 1:45=A0pm, Peter Flass
<Peter_Fl...@Yahoo.com> wrote:
> Eric Chomko wrote:
> > On Mar 3, 7:06 pm, Greg Menke <guse...@comcast.net> wrote:
> >> Peter Flass <Peter_Fl...@Yahoo.com> writes:
> >>> Michael Wojcik wrote:
> >>>> Peter Flass wrote:
> >>>>> Hey! =A0C's finally caught up to PL/I. =A0Only took them 50
years, =
and then
> >>>>> of course all the features are just tacked-on in true C fashion,
in=
stead
> >>>>> of thought-through.
> >>>> Well, that's rather insulting to the members of WG14, who spent a
> >>>> decade designing those features. Fortunately, they published the
> >>>> Rationale showing that, in fact, they were thought through.[1] And
a
> >>>> great deal of documentation describing the process is available in
t=
he
> >>>> archives.[2]
> >>>> If you'd care to show why you think otherwise, perhaps there would
b=
e
> >>>> some grounds for debate.
> >>> "The flexible array must be last"?
> >>> "sizeof applied to the structure ignores the array but counts any
> >>> padding before it"?
> >>> C is a collection of ad-hoc ideas. =A0WG14 may have put a great deal =
of
> >>> thought into how to extend it without breaking the existing mosh, but
> >>> that's my point, it's still a mosh.
> >> iostream formatting operators, because we really need more operator
> >> overloading and no enhancements are too bizarre in service of making
> >> everything, (for particular values of everything), specialized?
>
> >> Oh but wait, you can compile, install and dig your way through Boost s=
o
> >> as to avoid the fun & games of vanilla iostream.
>
> >> Thank goodness printf and friends are still around.
>
> > More generally when speaking about C++, than goodness C is still
> > around.
>
> I've said before, C started out as a fairly simple and clean language,
> with possibly a few rough spots. =A0Unfortunately instead of accepting it
> on its own terms, and maybe coming up with "D", people tried to turn it
> into a real 3GL, but then it gets in its own way. =A0It's lots of fun
> reading some of the Gnu stuff to see a language less readable than APL.- =
Hide quoted text -
>
> - Show quoted text -

I'm pretty much in Rip Van Winkle mode. Took a C class back in 1988
for the fun of it, managed to get an A in it, and kind of liked it.
Twenty years later I pop my head up and it might as well be
Hieroglyphs. Funny thing<to me> is the people running the show or part
of it love the way it evolved. I'm definately in the minority.

*BUT* not trying to wrap the drift back to FPGA or anything since I am
frequently guilty of drift myself, it is all interesting.

What I meant was more along the lines of hardware that would make a
language writer's job easier, a language that would execute faster, an
implementation that would be more robust.

Just as an example since the link I posted was a ref to the 65C02: The
hardware stack is only 256 bytes so passing parameters on the stack
can run into problems. You can have a software stack but branches have
to be within ~+-128. This leaves you with a software stack =3D> 16 bit
pointers, 64k limit, and slower then the other tools.

One of the other old processors from my stone knives and bear skin
days was the RCA1802. It had IMHO a great feature for the calling
subroutines. Anyone of the 16 general purpose registers could be made
the program counter with a single instruction.

The author of that web page decoded instructions on the buss to
implement his own set of register and instructions. IIRC he called one
register 'W' and it acted as an extended program counter so the memory
could be expanded to ~4 megs. Of course he did a lot more then that
with adding useful instructions.

I was just thinking if I wanted to have a faster 'C one of the things
I would like to do is implement the single instruction PC change. If
for example you had say 255 external 24 bit hardware registers in a
FPGA that would function as a PC you could have that many subroutines
implemented in a 2 byte instruction i.e. op code for next byte will be
PC register selection followed by a single byte. I would have to look
at the op codes available but you may be able to implement ~16
subroutine calls in a single byte. I think it could be done on the
cheap and simple with a small GAL and maybe a fast static ram to
contain the microcode and function as the W and PC registers. The 16
external registers would probably be enough if you choose the 16 most
called routines from the runt time code.

You could also implement runtime read only memory, memory moves by
blit, pattern matching for things like string search functions in a
form similar to blit, a second 'hardware stack' separate from main
memory.

Of course it comes back to my original statement that people could
just tell me to throw a Pentium at the problem and it would be valid
point.

Rick

Peter Flass wrote:
> Quadibloc wrote:
>> On Feb 22, 3:53 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
>>
>>> PL/I can be, but doesn't have to be.  If the arguments of a procedure
>>> match the parameters, only the argument address (and possibly a
>>> descriptor address for strings structures, and arrays) is passed.
>>
>> Doesn't PL/I (or, rather, normal implementations thereof) support
>> separate compilation of subroutines, just like FORTRAN and COBOL?
>>
> 
> Yes, but the calling sequence among PL/I programs passes information on 
> string  lengths, array bounds, etc.  You have to dumb it down to call 
> other languages.
> 
> For example, you can code:
>   a: PROCEDURE( array );
>     DECLARE array (*) CHARACTER(*);
>     DO i=1 to HBOUND(array);
>       DO j=1 TO LENGTH(array(i)); ... END;
>       END;
> 
> where both the upper limit of "array" is passed along with the string 
> length of the element.

ISTM that one of the design goals of C was to make function calls 
have a smaller overhead that other HLL's.

-- 
+----------------------------------------+
|     Charles and Francis Richmond       |
|                                        |
|  plano dot net at aquaporin4 dot com   |
+----------------------------------------+

Quadibloc wrote:
> On Mar 5, 12:44 pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
>> Quadibloc <jsav...@ecn.ab.ca> writes:
>>> On Feb 26, 4:56 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>>>>         No, he's saying that C doesn't really implement an array type,
the
>>>> var[offset] syntax is just syntactic sugar for *(var + offset) which is
why
>>>> things like 3[x] work the same as x[3] in C.
>>> Um, no.
>>> x = y + 3 ;
>>> in a C program will _not_ store in x the value of y plus the contents
>>> of memory location 3.
>>> On a big-endian machine,
>>> long int x[5] ;
>>> x[0] = 3 ;
>>> x[1] = 12 ;
>>> y = x[0] ;
>>> or, on a little-endian machine,
>>> long int x[5] ;
>>> x[1] = 3 ;
>>> x[0] = 12 ;
>>> y = x[1] ;
>>> will not result in zero being stored in y, since a long int variable
>>> occupies more than one byte in storage, and hence the two assignments
>>> are being made to overlapping variables.
>>> Yes, C doesn't do _bounds checking_, but that is a far cry from
>>> "syntactic sugar for variable plus address offset".
>> I'm not quite sure what the point of your example is, somebody who is
>> better at programming languages than me would have to evaluate the claim
>> that C arrays aren't arrays.  But:
>>
>> #include <stdio.h>
>> int main()
>> {
>>     int a[4];
>>
>>     printf("a[2] at 0x%8x\n", &(a[2]));
>>     printf("2[a] at 0x%8x\n", &(2[a]));
>>     printf("(a+2) is 0x%8x\n", a+2);
>>     printf("(2+a) is 0x%8x\n", 2+a);
>>
>> }
>>
>> [pfeiffer@snowball ~/temp]# ./awry
>> a[2] at 0xbfff97b8
>> 2[a] at 0xbfff97b8
>> (a+2) is 0xbfff97b8
>> (2+a) is 0xbfff97b8
> 
> The 2[a] syntax actually *works* in C the way it was described? I am
> astonished. I would expect it to yield the contents of the memory
> location a+&2 assuming that &2 can be persuaded to yield up the
> location where the value of the constant "2" is stored.
> 
> Evidently there is some discrepancy between C and FORTRAN.
> 
> John Savard

Yes, "2[c]" does work in C as well as "c[2]", and yields the same 
results. The definition of "c[x]" is "*(c+x)", where the array
"c" 
becomes a pointer to the first element, and the integer value "x" 
is scaled by the length associated with the pointer "c". "*(c+x)" 
will give the same result as "*(x+c)", so it's logical.

-- 
+----------------------------------------+
|     Charles and Francis Richmond       |
|                                        |
|  plano dot net at aquaporin4 dot com   |
+----------------------------------------+

Walter Bushell wrote:
> In article <2...@eircom.net>,
>  Ahem A Rivet's Shot <s...@eircom.net> wrote:
> 
>> On Fri, 5 Mar 2010 09:07:31 -0800 (PST)
>> Quadibloc <j...@ecn.ab.ca> wrote:
>>
>>> On Feb 26, 4:56Â am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>>>
>>>> Â  Â  Â  Â  No, he's saying that C doesn't really implement an array
type,
>>>> the var[offset] syntax is just syntactic sugar for *(var + offset)
>>>> which is why things like 3[x] work the same as x[3] in C.
>>> Um, no.
>>>
>>> x = y + 3 ;
>>>
>>> in a C program will _not_ store in x the value of y plus the contents
>>> of memory location 3.
>> 	No but x = *(y + 3) will store in x the contents of the memory
>> location at 3 + the value of y just as x = y[3] will and x = 3[y] will,
>> which is what I stated. You missed out the all important * and ()s.
> 
> No, that will compare x and the right val.
> 
> = is a comparasion operator in c.
> 
  "==" is a comparison operator in c.

-- 
+----------------------------------------+
|     Charles and Francis Richmond       |
|                                        |
|  plano dot net at aquaporin4 dot com   |
+----------------------------------------+