The Shark has a harvard architecture (separate code & data memories) if I recall correct. The Analog Devices Blackfin however has a single addressing range and that makes porting from the PC and back a whole lot easier.
That's why C has char, short and long types (8, 16 and 32 bit) independant of the architecture. At my daytime job we put a command line interpreter in most of the products to aid debugging. It's the same source for an HC11, H8/300 H8/3000S, a Windows service, a Windows DLL or a Linux deamon.
--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
"char" means character it is not always 8 bits on some machines that do not have byte addressing it can be quite a few more than 8 bits. In one case a "char" was in fact a 32 bit integer because that was the smallest grain that can be addressed.
"short" does not mean 16 bits and "long" does not mean 32. On most byte based processors this has become the defacto standard but if the processor is not byte based, the length is the natural lenth of the numbers in that machine in an ATT DSP chip a long integer was 24 bits for example.
Are you man enough to take it to C.A? Trust me, you'll get chewed up and spit out by people who do just this for a living.
Not I, I'm only a reporter (and can't stand 'C', BTW). I do either assembler or highly structured programming (VHDL is more my style ;-).
Nonsense. Take it to C.A. and report back with your tail burned off.
Of course not, pointers to structures are. But the basic types are defined in the language specification too. Because *you* choose to bastardize them, you shoot yourself in the foot. 'C' is really good at letting the incompetent do that (which is why I don't do 'C').
Tell it to the real programmers over on comp.arch, if you dare. I'll lurk and watch you burn too. I've seen these flame-fests before. The incompetents always run away with flaming tails.
Also ignoring Harvard architectures (like the 8051) and special function registers (which are obviously hardware dependant).
No, not C.A.C. It might work, but I meant C.A. I've seen exactly this argument before in C.A. I've never followed C.A., since I'm a hardware type. A Google NG search might keep from upsetting the natives too. ;-)
I'm only reporting what the language experts say. They claim to do portable C reliably, every time.
I never explicitly stated anything of the kind. I states simply that portable C coding was possible without out polluting the code with massive IFDEFs and such.
No, I meant "comp.arch", where much of this stuff has been hashed out ad-nausium. I've never followed comp.arch.c, so I know none of the regulars.
I've added the comp.arch news group to the header on this because the argument has moved into an area that the other poster claims I will get roarsted in. If you disagree with me, fire away. I think you will agree with my statements on the subject of C.
I've editted things down a bit to make the basic points easier to pick up on part way into the argument. You should be able to backtrack the thread in your news reader. If this ends up purely a comp.arch issue I'll delete the electronics news group.
The discussi>>
Consider it taken there if I did the headers right.
"the basic" types means the same as the "simple types". Or are you suggesting that some arrays or structures are now part of the language definition?
I maintain that "complex types" end up being machine dependant because they are defined from the "simple types". I have also said that "long int", "short int", "int", "float" and all pointers are machine dependant because thir meaning changes for non-byte oriented processors. Keith (the other poster) asserted that "short int" means 16 bits and that "long int" means 32 bits.
I actually looker for the support part and the STK501 seems to have more suport ! It has assembler program from ATMEL for example but not the MAVRIC .... so which one would you go with ??
I actually looker for the support part and the STK501 seems to have more suport ! It has assembler program from ATMEL for example but not the MAVRIC .... so which one would you go with ??
The STK boards are general purpose development tools. The Mavric is a designed for just the one processor.
Depends on what you want.
Both will work with AVR Studio, but with the Mavric, you'll need a programmer, like an AVRISP.
If you want a little board that you can embed in your project, then the mavric is a better choice. If you want to work with many different AVRs, then the STK is better.
Ok, I'll include that limitation to the scope of the argument. Things like the transputer are alos off the table. I think they are too weird to make a C compiler for. We can limit the discussion to only those machines for which a reasonable C compiler can be written.
If we don't get a reaction, one us will have to change the groups line. I did not because it is way too early to expect any reaction.
But ... but ... are they porting to microcontrollers etc. In the general purpose computer world things can be quite different. Companies like Prime and DEC no longer exist so there aren't many non-byte oriented general purpose computers any more.
I thought you did. Maybe I confused you with some other poster. Sorry if I did.
Well we will see if this get more hash or just ignored. Fasten your seat belt, it may be a bumpy ride.
In the last 2 decades microcontroller and DSP manufacturors started to make their processors to be easy programmable using C. Even DSPs with all their oddities to make them fast are getting better to program using C nowadays.
--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Yes, they are a lot better today. Better was easy to do since they were generally awful in the past.
DSPs still often have limitation on the smallest grain size and some don't use IEEE floats to do the actual floating calculations.
If C allowed you to specify the range of values and the minimum bits in mantissas etc. The processors would have had to change less to make them easy to program in C.
OTOH, I know people who use C compliers for 8051s. I couldn't figure out how to make it all work. (again, I'm a hardware type and think in RTL and assembler)
I added C.A. Though it may be a stale subject...
They've been doing it for decades. I've heard of very little x86 (32b) Linux code that isn't an "automatic" recompile to 64b. Of course 64b isn't new in the *ix world.
's ok. My statement is based on experts' opinions that porting isn't rocket surgery, but rather attention to detail. Sloppy is bad news and 'C' allows one to be as crude and rude as one is.
I am not much help with that. One thing I know. is BECARFULL buying from Digi Key
I am in australia and they charged me $87US($120AUD) for a Digi Key card board Box. the parts where around $30US.
I have gotten things from the US in the post for shit loads cheaper airfare than that. Digi key did end up giving me half the shipping cost back, after trying to rip me off. so in the end I still paid $45US for a card board box. legal scammers. Basically they sell card board boxes and throw in a few electronic components. But that might only be if you live in an other country. maybe they have a mentality of 'screw people in other countries besides the USA'
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.