glen herrmannsfeldt wrote:
> In comp.arch.fpga Charles Richmond <f...@tx.rr.com> wrote:
> (snip)
>  
>> The dimensions of arrays *used* to have to be compile time 
>> constants. Now they have a type of array declared in a function 
>> that can have its size depend on an integer passed into the 
>> function. (I forget what they call it...  maybe a "dynamic array" 
>> or something.)
> 
> Yes, but can you do that for an array in a struct.

No. The size of a struct type must be known at compile time, even in C99.

> If you
> pass it in a function call, and it isn't the last argument, how
> will the called routine know where the other arguments are?

If you *could* do this, that'd be an implementation issue, and outside
the scope of the C language. :-)

(Technically, C says nothing about a stack. A conforming C
implementation could use activation frames that contain XML documents
describing each parameter in detail. It could use an indexed file to
implement the call stack. It could implement calls by generating
subprograms on the fly that get their parameters via pipes. If they
get there on the backs of unicorns ridden by nasal demons, that's OK
with the standard too.)

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

Michael Wojcik <m...@newsguy.com> writes:

> Scott Lurndal wrote:
>> 
>> I've never promoted or suggested that one put an array in a struct
>> and pass it by value, I frankly think it would be a stupid thing to
>> do in a C program.
>
> Is it a stupid idea, or a good one, in all the languages that support
> it? Is this just a special attribute of C?
>
>> I was curious if anyone thought passing an array by value was a
>> _good_ idea.
>
> It might be if you want the callee to be able to modify its copy of
> the array without affecting the caller's. Just like any other
> pass-by-value object.

I think the point is that this is unlikely to be a good thing to do to
an array.  I'm not terribly sure it's often a good idea for anything
else, either!

> If the callee would have had to make a copy of the array anyway, why
> not let the compiler do the work?
-- 
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)

In comp.arch.fpga Michael Wojcik <m...@newsguy.com> wrote:
(snip on C, arrays, and such)
 
> Array types aren't first-class because when used as formal parameters
> they're converted to pointer types, and when used as actual parameters
> they decay to a pointer to their first element. This is similar to C's
> other second-class type, the function type, which decays to a function
> pointer in every context except declaration and definition.

How do you classify Fortran arrays.  (Specifically "assumed  size"
arrays in newer Fortran versions, the only ones they had in older
versions.)

Since Fortran doesn't use call by value, but allows either call by
reference or call by value result, there is no need for the "decay
to pointer to the first element."   The Fortran standard, since the
first standard in 1966, and still in Fortran 2008, allows one to
do things like:

      dimension x(100)
      call y(x(23))

and in the called routine

      subroutine y(z)
      dimension z(78)

where subroutine y gets the last 78 elements of array x.  The effect
is exactly the same as a C program passing x+22 as a pointer.

It is also legal to pass an array element of a multidimensional
array to a called routine with a dummy array with a different number
of dimensions (rank on Fortran terms).  It was very common for library
routines to dimension the dummy array (1) in the Fortran 66 days, or
(*) in later versions, and compute the appropriate offset in a two
(or more) dimensional actual argument (array in the calling routine).

Pointers were added to Fortran in Fortran 90, but don't have any
of these properties.  You can't do all the pointer addition tricks
that you can do in C with them.
 
> [1] Probably the best treatment of this question is in PvdL's _Expert
> C Programming_, chapter 4, "The Shocking Truth: C Arrays and Pointers
> Are NOT the Same!", and chapter 9, "More About Arrays".

-- glen 

On 26/02/2010 18:51, in article h...@news5.newsguy.com, "Michael
Wojcik" <m...@newsguy.com> wrote:

> (see below) wrote:
>> On 24/02/2010 20:37, in article h...@news6.newsguy.com, "Michael
>> Wojcik" <m...@newsguy.com> wrote:
>> 
>>> (see below) wrote:
>>>> But bear in mind that in decent languages arrays are
>>>> storable values, so a value array parameter gets copied in toto, unlike C.
>>> It will be in C if the array is wrapped in a struct. Letting array
>> 
>> That is passing a struct, not an array.
> 
> Yes, that's what I said. Of course, if the array is the only thing in
> the struct, then the distinction is purely syntactic.
> 
>>> struct (and not the misnamed "typedef") is C's mechanism for creating
>>> new types and ADTs, so if you want a pass-by-value array in C, the
>>> correct thing to do is to put it in a struct.
>> 
>> Yes. Preposterous, isn't it?
> 
> Other than the name of the keyword struct, no, it seems pretty
> reasonable to me. Parameters should be primitives or ADTs.

Ah. You are a fundamentalist.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Scott Lurndal wrote:
> "(see below)" <y...@blueyonder.co.uk> writes:
>> On 24/02/2010 20:37, in article h...@news6.newsguy.com, "Michael
>> Wojcik" <m...@newsguy.com> wrote:
>>
>>> (see below) wrote:
>>>> Just the usual red tape: return address, frame pointer of caller; and either
>>>> a static pointer or some housekeeping for 'display' registers (if used) to
>>>> access non-locals. But bear in mind that in decent languages arrays are
>>>> storable values, so a value array parameter gets copied in toto, unlike C.
>>> It will be in C if the array is wrapped in a struct. Letting array
>> That is passing a struct, not an array.
>>
>>> parameters decay to pointers was a feature of early C that couldn't be
>>> changed for historical reasons, but when the standardization committee
>>> added support for struct parameters, they made them first-class.
>>> struct (and not the misnamed "typedef") is C's mechanism for creating
>>> new types and ADTs, so if you want a pass-by-value array in C, the
>>> correct thing to do is to put it in a struct.
>> Yes. Preposterous, isn't it?
> 
> Q?  Why would anyone want to pass an array by value?
> 

Because you can?

Michael Wojcik wrote:
> glen herrmannsfeldt wrote:
>> In comp.arch.fpga Charles Richmond <f...@tx.rr.com> wrote:
>> (snip)
>>  
>>> The dimensions of arrays *used* to have to be compile time 
>>> constants. Now they have a type of array declared in a function 
>>> that can have its size depend on an integer passed into the 
>>> function. (I forget what they call it...  maybe a "dynamic array" 
>>> or something.)
>> Yes, but can you do that for an array in a struct.
> 
> No. The size of a struct type must be known at compile time, even in C99.
> 
>> If you
>> pass it in a function call, and it isn't the last argument, how
>> will the called routine know where the other arguments are?
> 
> If you *could* do this, that'd be an implementation issue, and outside
> the scope of the C language. :-)
> 
> (Technically, C says nothing about a stack. A conforming C
> implementation could use activation frames that contain XML documents
> describing each parameter in detail. It could use an indexed file to
> implement the call stack. It could implement calls by generating
> subprograms on the fly that get their parameters via pipes. If they
> get there on the backs of unicorns ridden by nasal demons, that's OK
> with the standard too.)
> 

Sure the implementation is left up to the compiler writer. But 
however the arguments are passed and the functions called, the 
implementation is *equivalent* to using a stack... because it 
accomplishes the same thing.

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

Peter Flass wrote:
> Scott Lurndal wrote:
>> "(see below)" <y...@blueyonder.co.uk> writes:
>>> On 24/02/2010 20:37, in article h...@news6.newsguy.com, "Michael
>>> Wojcik" <m...@newsguy.com> wrote:
>>>
>>>> (see below) wrote:
>>>>> Just the usual red tape: return address, frame pointer of caller; 
>>>>> and either
>>>>> a static pointer or some housekeeping for 'display' registers (if 
>>>>> used) to
>>>>> access non-locals. But bear in mind that in decent languages arrays 
>>>>> are
>>>>> storable values, so a value array parameter gets copied in toto, 
>>>>> unlike C.
>>>> It will be in C if the array is wrapped in a struct. Letting array
>>> That is passing a struct, not an array.
>>>
>>>> parameters decay to pointers was a feature of early C that couldn't be
>>>> changed for historical reasons, but when the standardization committee
>>>> added support for struct parameters, they made them first-class.
>>>> struct (and not the misnamed "typedef") is C's mechanism for creating
>>>> new types and ADTs, so if you want a pass-by-value array in C, the
>>>> correct thing to do is to put it in a struct.
>>> Yes. Preposterous, isn't it?
>>
>> Q?  Why would anyone want to pass an array by value?
>>
> 
> Because you can?

In C, you can *not*...   :-)

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

On Feb 5, 10:19=A0am, Eric Chomko <pne.cho...@comcast.net> wrote:
> Has anyone created a copy machine of an old system using an FPGA?

I havent, but check out:

applelogic.org  (it's down right now as far as I can tell)

http://www.mirrow.com/FPGApple/

http://mirrow.com/FPGApple/revisited.html

http://members.iinet.net.au/~msmcdoug/pace/#Status


http://www.applefritter.com/blog/12920

http://c64upgra.de/c-one/


looks like the mirrow.com links aren't working either...

rich12345 wrote:
> 
> I havent, but check out:
> 
> applelogic.org  (it's down right now as far as I can tell)
> 
> http://www.mirrow.com/FPGApple/
> 
> http://mirrow.com/FPGApple/revisited.html
> 
> looks like the mirrow.com links aren't working either...
> 

It has changed to alexfreed.com
So try
http://alexfreed.com/FPGApple

and

http://alexfreed.com/FPGApple/revisited

-Alex.



--- news://freenews.netfront.net/ - complaints: n...@netfront.net ---

On Fri, 26 Feb 2010 13:48:48 -0500
Michael Wojcik <m...@newsguy.com> wrote:

> Ahem A Rivet's Shot 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.
> 
> That's not quite correct. C does implement an array type (or, rather,
> an array type qualifier which can be used to implement arrays of any
> object type); it's just not first-class.

	This is saying the same thing as I did in different terms and with
greater detail.

-- 
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/