Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Mar 5, 8:08=A0am, Antti <antti.luk...@googlemail.com> wrote: > On Mar 5, 2:41=A0pm, Symon <symon_bre...@hotmail.com> wrote: > > > On 3/5/2010 11:39 AM, de4 wrote: > > > > Can someone show me an example of code in VHDL of simple state machin= e that > > > can be packed in to BRAM with any warnings, errors. I just worry that= my > > > design won't work. I have ISE 11.1 and Spartan 3a... > > > XAPP291 > > xapp291 does NOT show how from SM VHDL code a implementation using > BRAM is generated by the tools > > Antti This is a very simple design, easily implemented in BRAM (if speed permits) You have 7 states, therefore you need 3 (encoded) outputs You have 6 incoming condition or jump codes. You use the BRAM as a synchronous look-up table, using as address the combination of any jump code with any state code. That means you need 9 inputs, and the BRAM is thus 512 x 3. ( "512 x 6" in your posting is nonsense) In hardware you must feed the three output bits back to the address inputs. You can use any additional otherwise unused outputs as decoded state descriptors, but that does not change the basic design. I suppose you know that the addressing information is automatically registered before it addresses the BRAM (which is really a BROM with fixed data content) Do not use any additional output pipelining, optionally available in some devices. Unfortunately I cannot give you any VHDL code, but the basic understanding should help you. I have described and promoted this type of design for many years. Peter Alfke, formerly Xilinx Applications (some of you may remember me)Article: 146101
On Feb 22, 2:53=A0pm, Eric Chomko <pne.cho...@comcast.net> wrote: > This was pre-RISC days and the whole computer > architecture idea > based upon a high-level language never really took off. Nor did the > use of a medium > level language like Forth as far as I can tell. Well, naturally not. Both of those ideas got you less performance per dollar than the use of a conventional architecture, with compilation by a highly- optimizing FORTRAN compiler. I mean, computer cycles cost real money in those days. Later on, in the microcomputer era, the even less efficient use of interpreters like BASIC was popular because it was an easy way to bridge the gap between what the microprocessors could do, and what was convenient for people to program in. But serious applications - which, in the case of home computers, largely meant video games - were programmed in assembler, until things improved to the point where C was an alternative. John SavardArticle: 146102
On Mar 5, 5:34=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > Andy Peters <goo...@latke.net> writes: > > ModelSim has one project file (the .mpf) which is plain text and > > easily edited by hand. > > Various others have also mentioned project files and workspaces and > the like... > > Am I the only one that makes *no* use of the various "project things" > (either in Modelsim or Aldec)? =A0I just have a makefile and use the GUI > to run the sim (from "their" command-line) and show me the waveforms. > I guess I don't like to be tied to a tool (as much as I can manage) > much as I don't like to be tied to a particular silicon vendor (as > much as I can manage :) > > Am I missing something valuable, or is it just different? I doubt you are missing much of any real use. I find the GUI will save me a lot of typing when instantiating modules. I use the "generate test bench" feature to build a file with the meat and potatoes in it and I copy that to the higher level module. Otherwise if I was practiced in using make files with FPGA tools, I would be likely be doing that too. RickArticle: 146103
On Fri, 5 Mar 2010 09:07:31 -0800 (PST), Quadibloc <jsavard@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. Of course not, given that there is dereference operator anywhwere. On the other hand x = y + *((int*)3); would do what you want. You need to get that '*' in there. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 146104
On Fri, 5 Mar 2010 09:07:31 -0800 (PST) Quadibloc <jsavard@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. -- 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/Article: 146105
On Mar 4, 7:29=A0pm, Symon <symon_bre...@hotmail.com> wrote: > On 3/4/2010 12:46 PM, Eric Smith wrote: > > > time they ship product. =A0Successful startups usually have something > > that is *many* times better than the existing products, on some axis > > almost entirely orthogonal to the prior metrics. > > > Eric > > Mate, > Ever wonder if you've been doing this too long? Did you write that last > phrase with a straight face? > Cheers, Syms. Yeah, the funny thing is I understood it AND missed the inside joke entirely! RickArticle: 146106
Hello, Out of curiousity, why does your tristate buffer model drive an x instead of a z? - Nathan On Mar 5, 12:28=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Fri, 5 Mar 2010 02:22:20 +0000 (UTC), Giorgos Tzampanakis wrote: > >I've tried to use an inout reg with quartus and it doesn't give a > >warning. However, I read on the internet that an inout port can > >only be a wire. Which one is true? > > It is unquestionably true that an inout port must be a net > (wire), and also that you must connect a net to any inout > port when you instantiate the module. =A0"reg" on either > side of an inout port is definitely illegal. > > If your design uses the inout port in a unidirectional > manner, it is possible that synthesis might be able to > do something useful with a reg on one or other side of it. > However, the resulting illegal Verilog code will never > work in any simulator. =A0Don't do it. > > The classic use of an inout port, to provide a bidi > tri-state signal, is straightforward. =A0Inside the module > you need two signals or expressions - probably reg - > to provide the buffer enable and buffer data. =A0You then > use a continuous assign to imply the buffer: > > =A0 module has_bidi ( inout bidi, ...); > =A0 =A0 ... > =A0 =A0 reg bidi_enable; > =A0 =A0 reg bidi_drive_value; > =A0 =A0 wire bidi_receive_value; > =A0 =A0 ... > =A0 =A0 assign bidi =3D bidi_enable? bidi_drive_value: 1'bx; > =A0 =A0 assign bidi_receive_value =3D bidi; > =A0 =A0 ... > =A0 =A0 .... other logic to use "bidi_receive_value" > =A0 =A0 .... and generate "bidi_enable" and "bidi_drive_value" > =A0 endmodule > > The second "assign" does nothing more than renaming the port > for internal use, but it can often be convenient to do that. > -- > Jonathan BromleyArticle: 146107
On Mar 4, 3:14 pm, Andy Peters <goo...@latke.net> wrote: > On Mar 4, 11:56 am, Antti <antti.luk...@googlemail.com> wrote: > > > as Xilinx has dropped hard processor IP in the latest families it > > makes ACTEL the only FPGA vendor whos latest product family does have > > hard processor IP. > > Putting a processor inside an FPGA has proven to us to be a bigger > PITA than it's worth. Who exactly is "us"? Are you with Xilinx, Actel or someone else? > Consider than instead of V4FX, you can use an S3AN and a standalone > PPC and you'll pay a whole lot less. Plus the various Freescale PPCs > have DDR memory and Ethernet and DMA controllers that don't suck, and > you're not stuck with crappy tools. > > Embedding the processor in the FPGA is an interesting idea, but as > long as Brand X seems to think that the only people who do are the > types who want to run Linux on an FPGA, it's gonna suck for actual > embedded use. The big problem seems to be the problem of too many size combinations to be practical. Mixing FPGA, CPU, SRAM and Flash on one chip can't be all things to all people. Still, I think there are a few sweet spots that can be profitable. A smallish FPGA (~3000 to 5000 LUT4s) combined with a CM3 in the typical MCU memory combinations is a powerful device, especially if it is available with a decent dual CODEC in a package on the smaller side (100 pins or less). The cost of low end FPGAs seem to be I/O count driven, so a 5000 LUT4 FPGA can likely be combined with a CM3 (or maybe a CM0), etc, without increasing the cost significantly. I am paying $10 for a 3000 LUT4 FPGA in a 100 TQFP along with a $3 stereo CODEC. If I could get an MCU in that package with even just 64 kB of Flash it would allow a very space constrained product to really have some capabilities... if they could keep the cost down to $15 at qty 100. Other than Cypress, no one else seems to see this as a viable market. I'm still waiting to see if the Cypress PSOC5 is all its cracked up to be. The Actel parts are way too expensive from what I've heard and I think the PSOC5 will be too rich as well. RickArticle: 146108
On Mar 5, 10:00=A0am, "Maurice Branson" <trauben...@arcor.de> wrote: > Hi folks, > > I have been introduced to a project where I have to implement a TFT displ= ay > controlller on a low-cost FPGA like Spartan-3 or Spartan-6. The controlle= r > has to support at least XGA - 1024x768, SXGA - 1280x1024, UXGA - 1600x120= 0 > and WUXGA 1920x1200. I have to chose an appropriate platform now. As I am= a > total newbie in the field of image processing on FPGAs I would ask you fo= r > your recommendation about size and type of FPGA, especially in terms of > logic for video scaling and SRAM memories for frame buffer storage. > > Many thanks in advance. > > KR, Maurice Build your controller design and measure the size to pick the part you need. Anything else is speculation without a clear understanding of the design. BTW, a display controller is not "image processing". It is just a display controller. If you need to do image processing, you need to describe that in detail to include in your size estimate. RickArticle: 146109
On Fri, 5 Mar 2010 09:41:25 -0800 (PST), Nathan Bialke wrote: >Out of curiousity, why does your tristate buffer model drive an x >instead of a z? ah, good catch. Runs for cover with tail between legs. Of course you're right, it should have been assign bidi = bidi_enable? bidi_drive_value: 1'bz; Errrrm, that's what simulators are for, right? To catch the idiotic typing mistakes? Thanks! -- Jonathan BromleyArticle: 146110
Nathan Bialke <nathan@bialke.com> writes: > Hello, > > Out of curiousity, why does your tristate buffer model drive an x > instead of a z? In my experience this is a fairly common technique to make sure some other part of the design isn't erroneously reading the x values and passing them on.Article: 146111
In comp.arch.fpga Quadibloc <jsavard@ecn.ab.ca> wrote: > On Mar 4, 1:20?pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: (regarding the design of the 360/195 or 360/91) >> Does anyone know if the information needed to do that still exists? > I suspect it was _very_ closely guarded back in the day, because it > would have been a matter of very serious concern had the Russians been > able to make a 360/195 equivalent to top out their RJAD/EC line. So > I'm thinking more along the line of a design from scratch to match the > public specifications, working from the 360/91 descriptions in the > open literature, and adding a cache (which shouldn't be too difficult, > there being caches on OpenCores). I'm not saying *I* could do stuff > like that on my very own, but there's a lot out there one could use as > a starting point. An important part of the design is the Earle latch, which combines one level of logic with the latch function. That is, what is sometimes called a transparent latch, instead of the edge triggered D flip-flop commonly available in FPGAs. There is a lot of literature on the floating point unit, though I don't know if near enough to reconstruct one. For the rest of the processor, I have seen very little. I believe that there is some effort towards implementing the 360/30 harware to execute actual 360/30 microcode. -- glen -- glenArticle: 146112
In comp.arch.fpga Quadibloc <jsavard@ecn.ab.ca> 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? I missed the beginning of this thread, but... Yes, PL/I, at least IBM's implementations, support separate compilation. In some cases that requires declaring the argument types in the calling routine such that appropriate conversion can be done. Otherwise, it would be way too hard to use many routines, with constants having the attributes in which they are written. If a routine expected fixed bin(31,0), for example, you couldn't call it with 1, which would be fixed dec(1), but would have to use 0000000000000000000000000000001B instead. Declaring it as needing fixed bin(31,0), allows the compiler to do the conversion either at compile or run time. -- glenArticle: 146113
Peter Alfke <alfke@sbcglobal.net> wrote: (snip) > Peter Alfke, formerly Xilinx Applications (some of you may remember me) and also notice that you don't post as often as before. I was not so long ago thinking of asking: There is picoblaze (8 bit), and microblaze (32 bit), but no nanoblaze (16 bit) or milliblaze (64 bit). It might even be interesting to have a femtoblaze (4 bit) processor. Maybe not so far off topic, as such processors are, at some level, complicated state machines. -- glenArticle: 146114
Quadibloc <jsavard@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
--
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)
Article: 146115Quadibloc <jsavard@ecn.ab.ca> writes: > I suspect it was _very_ closely guarded back in the day, because it > would have been a matter of very serious concern had the Russians been > able to make a 360/195 equivalent to top out their RJAD/EC line. So > I'm thinking more along the line of a design from scratch to match the > public specifications, working from the 360/91 descriptions in the > open literature, and adding a cache (which shouldn't be too difficult, > there being caches on OpenCores). I'm not saying *I* could do stuff > like that on my very own, but there's a lot out there one could use as > a starting point. 370/195 had some extra instructions & instruction retry added to improve reliability. 195 had 64 instruction pipeline and imprecise interrupts. 195 didn't have branch prediction or speculative execution ... so branches (except for special case loop within pipeline) drained the pipeline. peak-speed was 10mips ... but most codes ran at half that because of the frequency of branches draining pipeline. there was effort to do form of hyperthreading ... looking like multiprocessor with two instruction streams ... one-bit tag indicating which i-stream an instruction was associated with; basically same pipeline, same execution units ... but having two i-streams had better chance of running at peak thruput. I wasn't directly involved in the hardware ... just got brought in to look at running multiprocessor kernel/software for the machine. 195 never got virtual memory. SJR had 370/195 up thru end of 1978 running MVT. -- 42yrs virtualization experience (since Jan68), online at home since Mar1970Article: 146116
On Mar 5, 11:10=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Peter Alfke <al...@sbcglobal.net> wrote: > > (snip) > > > Peter Alfke, formerly Xilinx Applications (some of you may remember me) > > and also notice that you don't post as often as before. > > I was not so long ago thinking of asking: > > =A0 =A0There is picoblaze (8 bit), and microblaze (32 bit), but no > =A0 =A0nanoblaze (16 bit) or milliblaze (64 bit). =A0It might even > =A0 =A0be interesting to have a femtoblaze (4 bit) processor. > > Maybe not so far off topic, as such processors are, at some level, > complicated state machines. > > -- glen Blazes... "Picoblaze" was started by Ken Chapman (still at Xilinx UK) as a highly optimized design, an app note that works well with 4-input LUTs and BRAMs. Xilinx has unfortunately always treated it as an illiigitimate child. (NIH) It lives due to its efficiency, and due to Ken's competence, enthusiasm, and perseverance. "Microblaze" was started by Goran Bilski (originally in Sweden, and now, after some years in Calif., back again in Sweden.) It has always been treated as a legitimate Xilinx baby, and Goran has continuously improved it, and more designers are involved. It grew from 16 bits to 32 bits. Still a highly optimized design. I have no idea about plans for 64 bits. I visit the Xilinx cafeteria once every couple of months to chat with old friends. I did repeatedly offer my services as a consultant, even without pay, but there are no takers. Peter A.Article: 146117
On Mar 5, 10:15=A0am, rickman <gnu...@gmail.com> wrote:
> On Mar 5, 5:34=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
>
> > Andy Peters <goo...@latke.net> writes:
> > > ModelSim has one project file (the .mpf) which is plain text and
> > > easily edited by hand.
>
> > Various others have also mentioned project files and workspaces and
> > the like...
>
> > Am I the only one that makes *no* use of the various "project things"
> > (either in Modelsim or Aldec)? =A0I just have a makefile and use the GU=
I
> > to run the sim (from "their" command-line) and show me the waveforms.
> > I guess I don't like to be tied to a tool (as much as I can manage)
> > much as I don't like to be tied to a particular silicon vendor (as
> > much as I can manage :)
>
> > Am I missing something valuable, or is it just different?
>
> I doubt you are missing much of any real use. =A0I find the GUI will
> save me a lot of typing when instantiating modules. =A0I use the
> "generate test bench" feature to build a file with the meat and
> potatoes in it and I copy that to the higher level module.
>
> Otherwise if I was practiced in using make files with FPGA tools, I
> would be likely be doing that too.
I don't use any of the Aldec tools that automatically generate test
benches or creating instances and all of that. Yes, I'm an emacs vhdl-
mode user and emacs does a fantabulous job of all of that.
Right now I'm working through the "best" way to set up projects within
the GUI, with an eye towards taking this and generating a Makefile or
a script or something.
It turns out that it is reasonable to create one workspace for an FPGA
project and within this workspace create a "design" for the
subentities and the top level. If you let it use the design name as
the working library for the design, then as long as you "use" the
library in a higher-level source, that source can see those other
libraries.
Now I'm thinking that the usual method of doing:
u_foo : entity work.foo port map (bar =3D> bar, bletch =3D> bletch);
might be better as:
u_foo : entity foo.foo port map (bar =3D> bar, bletch =3D> bletch);
The other option is to create a package with a component definition
for foo, and analyze that package into the foo library, so the
instantiation can be:
u_foo : foo port map (bar =3D> bar, bletch =3D> bletch);
I really don't know which is "better."
-a
Article: 146118On Mar 5, 10:44=A0pm, Antti <antti.luk...@googlemail.com> wrote: > recognized by Actel also, specially A2F060 must come to low > price.. Hi Antti, Did you get everything finished for ESC ok > Speaking of low prices, have you seen price indicators yet on the SiliconBlue iCE65L01 ? (other than the 99c/1M pieces) - a 1K-10K price is more useful :) - and availability timelines ? -jgArticle: 146119
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.
Article: 146120On 5 Mrz., 16:00, "Maurice Branson" <trauben...@arcor.de> wrote: > I have been introduced to a project where I have to implement a TFT display > controlller on a low-cost FPGA like Spartan-3 or Spartan-6. The controller > has to support at least XGA - 1024x768, SXGA - 1280x1024, UXGA - 1600x1200 > and WUXGA 1920x1200. I have to chose an appropriate platform now. As I am a > total newbie in the field of image processing on FPGAs I would ask you for > your recommendation about size and type of FPGA, especially in terms of > logic for video scaling and SRAM memories for frame buffer storage. From my pesonal experience of porting my display contol / scaler ASIC to a FPGA i would recommend Lattice ECP2/3. I think their timing Performance is significantly better than Spartan 3 making it not too difficult to achieve the timing you need for what you say. But it looks like all this could keep you busy for a few years as a "total newbie".Article: 146121
"Adam Górski" <totutousungorskia@malpawp.pl> wrote in message news:hmqv2n$5qr$1@atlantis.news.neostrada.pl... > rickman pisze: >> On Mar 4, 7:42 am, Adam Górski <totutousungors...@malpawp.pl> wrote: >>> Pete Fraser pisze: ..>>> Use Remote desktop or similar . >>> You can have really powerful PC for fpga compilation this way. >>> If you have inet connection of course. >>> >>> Adam >> >> Way back when, this software was purchased (PC Anywhere sticks in my >> mind). Then I believe MS included it with WinXP, that was how IT used >> to "fix" my PC. But I see now it is back to being commercial >> software. This this software different somehow than the stuff they >> had in WinXP or is that gone again? > > Remote desktop is included in WinXp Profesional and higher. > also in Vista Pro and higher. Just as a warning a number of Flexlm based software is blocking remote desktop so you won't be able to run a node-locked license using remote desktop. VNC and others work fine, Hans www.ht-lab.com > > AdamArticle: 146122
On Mar 5, 10:16=A0am, Ahem A Rivet's Shot <ste...@eircom.net> wrote: > =A0 =A0 =A0 =A0 No but x =3D *(y + 3) will store in x the contents of the= memory > location at 3 + the value of y just as x =3D y[3] will and x =3D 3[y] wil= l, > 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. If C doesn't have "real" arrays, it at least makes a rather good 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. John SavardArticle: 146123
Peter Alfke wrote: > I did repeatedly offer my services as a consultant, even without pay, > but there are no takers. Is it because of "budget restrictions" or because... you're outside the company's loop now ? are you an "outcast" already ? > Peter A. yg -- http://ygdes.com / http://yasep.orgArticle: 146124
On Mar 5, 12:44=A0pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
> Quadibloc <jsav...@ecn.ab.ca> writes:
> > On Feb 26, 4:56=A0am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>
> >> =A0 =A0 =A0 =A0 No, he's saying that C doesn't really implement an arr=
ay type, the
> >> var[offset] syntax is just syntactic sugar for *(var + offset) which i=
s why
> >> things like 3[x] work the same as x[3] in C.
>
> > Um, no.
>
> > x =3D 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] =3D 3 ;
> > x[1] =3D 12 ;
> > y =3D x[0] ;
>
> > or, on a little-endian machine,
>
> > long int x[5] ;
> > x[1] =3D 3 ;
> > x[0] =3D 12 ;
> > y =3D 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. =A0But:
>
> #include <stdio.h>
> int main()
> {
> =A0 =A0 int a[4];
>
> =A0 =A0 printf("a[2] at 0x%8x\n", &(a[2]));
> =A0 =A0 printf("2[a] at 0x%8x\n", &(2[a]));
> =A0 =A0 printf("(a+2) is 0x%8x\n", a+2);
> =A0 =A0 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
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z