elektroda.net NewsGroups Forum Index - FPGA - using an FPGA to emulate a vintage computer
Goto page Previous 1, 2, 3 ... 13, 14, 15, 16 Next
Joe Pfeiffer
Guest
Guest
Sun Mar 07, 2010 3:57 am
Quadibloc <jsavard_at_ecn.ab.ca> writes:
Quote:
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.
I don't have my copy handy, but I think it was documented that way back
in the original C language Bell Labs tech report.
--
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)
Patrick Scheible
Guest
Guest
Sun Mar 07, 2010 4:08 am
Charles Richmond <frizzle_at_tx.rr.com> writes:
Quote:
Peter Flass wrote:
Walter Bushell wrote:
In article <20100305171635.e538ef18.steveo_at_eircom.net>,
Ahem A Rivet's Shot <steveo_at_eircom.net> wrote:
On Fri, 5 Mar 2010 09:07:31 -0800 (PST)
Quadibloc <jsavard_at_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.
I think there is *not* a single C programmer who has *not* had his
hand slapped by making the mistake of using "=" when he meant
"==".
Walter Bushell wrote:
In article <20100305171635.e538ef18.steveo_at_eircom.net>,
Ahem A Rivet's Shot <steveo_at_eircom.net> wrote:
On Fri, 5 Mar 2010 09:07:31 -0800 (PST)
Quadibloc <jsavard_at_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.
I think there is *not* a single C programmer who has *not* had his
hand slapped by making the mistake of using "=" when he meant
"==".
More than once...
-- Patrick
Dennis Ritchie
Guest
Guest
Sun Mar 07, 2010 5:33 am
"Quadibloc" <jsavard_at_ecn.ab.ca> wrote in message
news:91a047d3-ee98-40b6-876e-9a7221168d5b_at_33g2000yqj.googlegroups.com...
Quote:
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.
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.
Yes, it really does work as described, and was indeed documented
in the earliest C, and for that matter B and BCPL manuals.
C and Fortran are discrepant here.
Dennis
Uwe Kloß
Guest
Guest
Sun Mar 07, 2010 7:33 am
Quadibloc schrieb:
Quote:
On Mar 5, 12:44 pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
#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_at_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.
#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_at_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.
You can think of the "a" in "a[4]" as a named numerical (integer)
constant (alias), giving the address of the memory block that was
allocated by the definition.
So there is no difference, between using that (named) constant or an
explicit numerical constant.
The only differences between:
(1) int a[4];
and:
(2) int * a = malloc( 4 * sizeof(int));
is the place where the memory is allocated and the value in (2) may be
changed later. (And the amount of typing, ofcourse!)
In both cases you can use "a[1]" or "*(a+1)" for access.
Quote:
Evidently there is some discrepancy between C and FORTRAN.
Only "a tiny bit"!
Only "a tiny bit"!
Grüße,
Uwe
Ahem A Rivet's Shot
Guest
Guest
Sun Mar 07, 2010 9:18 am
On Sat, 06 Mar 2010 15:03:52 -0500
Walter Bushell <proto_at_panix.com> wrote:
Quote:
No, that will compare x and the right val.
= is a comparasion operator in c.
= is a comparasion operator in c.
Bzzzt wrong!
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Ahem A Rivet's Shot
Guest
Guest
Sun Mar 07, 2010 9:29 am
On Sat, 6 Mar 2010 01:58:43 -0800 (PST)
Quadibloc <jsavard_at_ecn.ab.ca> wrote:
Quote:
On Mar 5, 10:16Â am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
    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.
Intentionally. My point was that, while there is _some_ truth to the
claim that C arrays tread rather lightly on the ground of hardware
addressing, the claim that C doesn't have arrays at all, and the C
array subscript operator does nothing at all but add two addresses
together... is not *quite* true.
    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.
Intentionally. My point was that, while there is _some_ truth to the
claim that C arrays tread rather lightly on the ground of hardware
addressing, the claim that C doesn't have arrays at all, and the C
array subscript operator does nothing at all but add two addresses
together... is not *quite* true.
The C subscript operator does do nothing other than adding two
numbers and dereferencing the result, that last action is rather important.
The validity of constructs like 2[a] and *(2+a) make this clear - as does
the equivalence of a and &(a[0]) or of *a and a[0] where a is a pointer.
C does have good support for pointers and adding integers to
pointers and for declaring blocks of storage with an array like syntax.
Quote:
If C doesn't have "real" arrays, it at least makes a rather good
Arrays are not a real type in C if they were they would be passed
by value in function calls instead of being passed by reference and it
would be necessary to use a construct like &(a[0]) to pass the address of
the first element of the array instead of just a.
Quote:
attempt to simulate them. Unless one's standards are such that FORTRAN
doesn't quite have "real" arrays either, and you need to go to Pascal
for real arrays, there isn't that much to complain about in the case
of C.
doesn't quite have "real" arrays either, and you need to go to Pascal
for real arrays, there isn't that much to complain about in the case
of C.
I am not saying that the C arrays are not useful as they are, just
that they fall short of being a type in the sense that int, char, long,
pointer and struct are.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Ahem A Rivet's Shot
Guest
Guest
Sun Mar 07, 2010 9:45 am
On Sat, 6 Mar 2010 02:01:30 -0800 (PST)
Quadibloc <jsavard_at_ecn.ab.ca> wrote:
Quote:
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.
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.
Yes of course it does - why else would I have mentioned it in my
first post in this threadlet ? a is a pointer, 2 is in a integer and 2[a]
is the same as a[2] is the same as *(a+2) and the rules for adding pointers
and integers are well defined in C. This is the heart of my original point,
array notation in C is syntactic sugar for pointer arithmetic (and also
for allocation which I neglected to mention in my original post).
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Greg Menke
Guest
Guest
Sun Mar 07, 2010 1:48 pm
Ahem A Rivet's Shot <steveo_at_eircom.net> writes:
Quote:
On Sat, 6 Mar 2010 01:58:43 -0800 (PST)
Quadibloc <jsavard_at_ecn.ab.ca> wrote:
On Mar 5, 10:16 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
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.
Intentionally. My point was that, while there is _some_ truth to the
claim that C arrays tread rather lightly on the ground of hardware
addressing, the claim that C doesn't have arrays at all, and the C
array subscript operator does nothing at all but add two addresses
together... is not *quite* true.
The C subscript operator does do nothing other than adding two
numbers and dereferencing the result, that last action is rather important.
The validity of constructs like 2[a] and *(2+a) make this clear - as does
the equivalence of a and &(a[0]) or of *a and a[0] where a is a pointer.
Quadibloc <jsavard_at_ecn.ab.ca> wrote:
On Mar 5, 10:16 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
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.
Intentionally. My point was that, while there is _some_ truth to the
claim that C arrays tread rather lightly on the ground of hardware
addressing, the claim that C doesn't have arrays at all, and the C
array subscript operator does nothing at all but add two addresses
together... is not *quite* true.
The C subscript operator does do nothing other than adding two
numbers and dereferencing the result, that last action is rather important.
The validity of constructs like 2[a] and *(2+a) make this clear - as does
the equivalence of a and &(a[0]) or of *a and a[0] where a is a pointer.
Yet when dereferencing arrays of rank >= 2, dimensions are automatically
incorporated into the effective address, so its not quite equivalent to
a simple addition of pointer and offset.
Gregm
Ahem A Rivet's Shot
Guest
Guest
Sun Mar 07, 2010 3:30 pm
On Sun, 07 Mar 2010 07:48:01 -0500
Greg Menke <gusenet_at_comcast.net> wrote:
Quote:
Ahem A Rivet's Shot <steveo_at_eircom.net> writes:
On Sat, 6 Mar 2010 01:58:43 -0800 (PST)
Quadibloc <jsavard_at_ecn.ab.ca> wrote:
On Mar 5, 10:16Â am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
    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.
Intentionally. My point was that, while there is _some_ truth to the
claim that C arrays tread rather lightly on the ground of hardware
addressing, the claim that C doesn't have arrays at all, and the C
array subscript operator does nothing at all but add two addresses
together... is not *quite* true.
The C subscript operator does do nothing other than adding two
numbers and dereferencing the result, that last action is rather
important. The validity of constructs like 2[a] and *(2+a) make this
clear - as does the equivalence of a and &(a[0]) or of *a and a[0]
where a is a pointer.
Yet when dereferencing arrays of rank >= 2, dimensions are automatically
incorporated into the effective address, so its not quite equivalent to
a simple addition of pointer and offset.
There is a way to regard it as such - consider a[x][y] as being
equivalent to *(a[x] + y) where we regard a[x] as devolving into a pointer
to a row of the array. But yes multidimensional array support is a little
more involved than single dimensional array support. It's still not a
proper type though.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Quadibloc
Guest
Guest
Sun Mar 07, 2010 3:35 pm
On Mar 7, 1:45 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
Quote:
On Sat, 6 Mar 2010 02:01:30 -0800 (PST)
Quadibloc <jsav...@ecn.ab.ca> wrote:
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.
Yes of course it does - why else would I have mentioned it in my
first post in this threadlet ? a is a pointer, 2 is in a integer and 2[a]
is the same as a[2] is the same as *(a+2) and the rules for adding pointers
and integers are well defined in C. This is the heart of my original point,
array notation in C is syntactic sugar for pointer arithmetic (and also
for allocation which I neglected to mention in my original post).
Quadibloc <jsav...@ecn.ab.ca> wrote:
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.
Yes of course it does - why else would I have mentioned it in my
first post in this threadlet ? a is a pointer, 2 is in a integer and 2[a]
is the same as a[2] is the same as *(a+2) and the rules for adding pointers
and integers are well defined in C. This is the heart of my original point,
array notation in C is syntactic sugar for pointer arithmetic (and also
for allocation which I neglected to mention in my original post).
If a[2] was the same as *(a+2), then, indeed, since addition is
commutative, it would make sense that 2[a], being the same as *(2+a),
would be the same.
But a[2] is the same as *(&a+2) which is why I expected 2[a] to be the
same as *(&2+a).
Unless in *(a+2) "a" suddenly stops meaning what I would expect it to
mean. In that case, C has considerably more profound problems than not
having arrays.
John Savard
Ahem A Rivet's Shot
Guest
Guest
Sun Mar 07, 2010 3:39 pm
On Sun, 7 Mar 2010 05:35:51 -0800 (PST)
Quadibloc <jsavard_at_ecn.ab.ca> wrote:
Quote:
On Mar 7, 1:45Â am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
On Sat, 6 Mar 2010 02:01:30 -0800 (PST)
Quadibloc <jsav...@ecn.ab.ca> wrote:
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.
    Yes of course it does - why else would I have mentioned it in my
first post in this threadlet ? a is a pointer, 2 is in a integer and 2
[a] is the same as a[2] is the same as *(a+2) and the rules for adding
pointers and integers are well defined in C. This is the heart of my
original point, array notation in C is syntactic sugar for pointer
arithmetic (and also for allocation which I neglected to mention in my
original post).
If a[2] was the same as *(a+2), then, indeed, since addition is
On Sat, 6 Mar 2010 02:01:30 -0800 (PST)
Quadibloc <jsav...@ecn.ab.ca> wrote:
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.
    Yes of course it does - why else would I have mentioned it in my
first post in this threadlet ? a is a pointer, 2 is in a integer and 2
[a] is the same as a[2] is the same as *(a+2) and the rules for adding
pointers and integers are well defined in C. This is the heart of my
original point, array notation in C is syntactic sugar for pointer
arithmetic (and also for allocation which I neglected to mention in my
original post).
If a[2] was the same as *(a+2), then, indeed, since addition is
Which it is by definition.
Quote:
commutative, it would make sense that 2[a], being the same as *(2+a),
would be the same.
But a[2] is the same as *(&a+2) which is why I expected 2[a] to be the
same as *(&2+a).
would be the same.
But a[2] is the same as *(&a+2) which is why I expected 2[a] to be the
same as *(&2+a).
No it's not - a in this context is treated as a pointer.
Quote:
Unless in *(a+2) "a" suddenly stops meaning what I would expect it to
mean.
mean.
Well I think you'll find a never die mean as what you would
expect it to mean. In many contexts including this one (and a[2] and 2[a]
and a + 2 or even (a+2)[3]) it is a pointer not an array - the only context
in which it is an array is the declaration.
Quote:
In that case, C has considerably more profound problems than not
having arrays.
having arrays.
C is consistent it's just that the array syntax really is a thin
mask for pointer arithmetic - even the multidimensional array syntax but
that's more fiddly.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Ahem A Rivet's Shot
Guest
Guest
Sun Mar 07, 2010 7:09 pm
On Sun, 7 Mar 2010 09:54:04 -0800 (PST)
Quadibloc <jsavard_at_ecn.ab.ca> wrote:
Quote:
On Mar 7, 7:39Â am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
    Well I think you'll find a never die mean as what you would
expect it to mean. In many contexts including this one (and a[2] and 2
[a] and a + 2 or even (a+2)[3]) it is a pointer not an array - the only
context in which it is an array is the declaration.
Yes: the array name always refers to the pointer, and the subscript is
required to reference, not just to displace. That was my mistake; a
never did mean the "array" in the abstract sense... so that a "new,
improved" C copying Fortran 90 (or PL/I) could have statements like
int a[5],b[5] ;
...
b = a + 2 ;
and the compiler just makes
int a[5],b[5]
...
for (i00001 = 0; i++; i<5 )
{ b[i00001] = a[i00001] + 2
} ;
    Well I think you'll find a never die mean as what you would
expect it to mean. In many contexts including this one (and a[2] and 2
[a] and a + 2 or even (a+2)[3]) it is a pointer not an array - the only
context in which it is an array is the declaration.
Yes: the array name always refers to the pointer, and the subscript is
required to reference, not just to displace. That was my mistake; a
never did mean the "array" in the abstract sense... so that a "new,
improved" C copying Fortran 90 (or PL/I) could have statements like
int a[5],b[5] ;
...
b = a + 2 ;
and the compiler just makes
int a[5],b[5]
...
for (i00001 = 0; i++; i<5 )
{ b[i00001] = a[i00001] + 2
} ;
Yes that would be nice, especially if it extended to full blown matrix
artihmetic.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Quadibloc
Guest
Guest
Sun Mar 07, 2010 7:54 pm
On Mar 7, 7:39 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
Quote:
Well I think you'll find a never die mean as what you would
expect it to mean. In many contexts including this one (and a[2] and 2[a]
and a + 2 or even (a+2)[3]) it is a pointer not an array - the only context
in which it is an array is the declaration.
expect it to mean. In many contexts including this one (and a[2] and 2[a]
and a + 2 or even (a+2)[3]) it is a pointer not an array - the only context
in which it is an array is the declaration.
Yes: the array name always refers to the pointer, and the subscript is
required to reference, not just to displace. That was my mistake; a
never did mean the "array" in the abstract sense... so that a "new,
improved" C copying Fortran 90 (or PL/I) could have statements like
int a[5],b[5] ;
....
b = a + 2 ;
and the compiler just makes
int a[5],b[5]
....
for (i00001 = 0; i++; i<5 )
{ b[i00001] = a[i00001] + 2
} ;
out of it.
John Savard
John Francis
Guest
Guest
Sun Mar 07, 2010 8:59 pm
In article <20100307143020.fcc7e3df.steveo_at_eircom.net>,
Ahem A Rivet's Shot <steveo_at_eircom.net> wrote:
Quote:
On Sun, 07 Mar 2010 07:48:01 -0500
Greg Menke <gusenet_at_comcast.net> wrote:
Ahem A Rivet's Shot <steveo_at_eircom.net> writes:
The C subscript operator does do nothing other than adding two
numbers and dereferencing the result, that last action is rather
important. The validity of constructs like 2[a] and *(2+a) make this
clear - as does the equivalence of a and &(a[0]) or of *a and a[0]
where a is a pointer.
Yet when dereferencing arrays of rank >= 2, dimensions are automatically
incorporated into the effective address, so its not quite equivalent to
a simple addition of pointer and offset.
There is a way to regard it as such - consider a[x][y] as being
equivalent to *(a[x] + y) where we regard a[x] as devolving into a pointer
to a row of the array. But yes multidimensional array support is a little
more involved than single dimensional array support. It's still not a
proper type though.
Greg Menke <gusenet_at_comcast.net> wrote:
Ahem A Rivet's Shot <steveo_at_eircom.net> writes:
The C subscript operator does do nothing other than adding two
numbers and dereferencing the result, that last action is rather
important. The validity of constructs like 2[a] and *(2+a) make this
clear - as does the equivalence of a and &(a[0]) or of *a and a[0]
where a is a pointer.
Yet when dereferencing arrays of rank >= 2, dimensions are automatically
incorporated into the effective address, so its not quite equivalent to
a simple addition of pointer and offset.
There is a way to regard it as such - consider a[x][y] as being
equivalent to *(a[x] + y) where we regard a[x] as devolving into a pointer
to a row of the array. But yes multidimensional array support is a little
more involved than single dimensional array support. It's still not a
proper type though.
That's all very well, but in fact no C implementation of which I am
aware uses dope vectors when allocating multidimensional arrays. (I
have come across the practice in other languages). In fact C has to
perform different calculations to evaluate the address of an element
a[i][j], depending on how a was defined (int a[4][5], or int** a).
The sizeof operator also knows something about array types.
glen herrmannsfeldt
Guest
Guest
Sun Mar 07, 2010 10:13 pm
In comp.arch.fpga John Francis <johnf_at_panix.com> wrote:
(snip)
Quote:
That's all very well, but in fact no C implementation of which I am
aware uses dope vectors when allocating multidimensional arrays. (I
have come across the practice in other languages). In fact C has to
perform different calculations to evaluate the address of an element
a[i][j], depending on how a was defined (int a[4][5], or int** a).
The sizeof operator also knows something about array types.
aware uses dope vectors when allocating multidimensional arrays. (I
have come across the practice in other languages). In fact C has to
perform different calculations to evaluate the address of an element
a[i][j], depending on how a was defined (int a[4][5], or int** a).
The sizeof operator also knows something about array types.
VMS compilers are supposed to allow for value, reference, or
descriptor argument passing to support interlanguage calls.
The %val(), %ref(), and %descr() syntax is supposed to be
supported by all compilers.
-- glen
elektroda.net NewsGroups Forum Index - FPGA - using an FPGA to emulate a vintage computer
