Searching \ for '[PIC] I say it is spinach and to hell with it!' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=spi
Search entire site for: 'I say it is spinach and to hell with it!'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] I say it is spinach and to hell with it!'
2005\08\15@211746 by William Chops Westfield

face picon face
John Nall wrote:
> This C30 stuff is not C.  It is related to the C
> language, true.  But C is device independent   C30 is definitely not!

Are you complaining about the way it is used, or the way the
language itself has been augmented?  I don't see how there is
any way around the former, but wouldn't mind looking at a
flame-worthy example of the latter...

BillW

2005\08\15@214830 by Maarten Hofman

face picon face
> Are you complaining about the way it is used, or the way the
> language itself has been augmented?  I don't see how there is
> any way around the former, but wouldn't mind looking at a
> flame-worthy example of the latter...

Yes, flames and trolls... Let them come... My apologies in advance for this.

> > This C30 stuff is not C.  It is related to the C
> > language, true.  But C is device independent   C30 is definitely not!

Modern ANSI C might be device independent to a certain extent.
However, the C language was never intended to be such. In fact, it is
a glorified version of assembly, originally written for a specific
type of processor. It has clear shortcuts (++ for "increment register"
for example) meant to map directly on certain assembly instructions.
At the time it was developed there were many devices on which C was an
excruciatingly slow language, not resulting in viable applications.
Then C became more popular and manufacturers began to make sure their
devices were able to run C, because the users demanded it.

But even now there are various devices (I think most of the <18F
PICmicro line falls into that category) that are not entirely suited
for this purpose, and an implementation of ANSI C on these devices,
though possible, would be so costly that an application written in
that language would not run very well on them. A version of C
specifically designed for such devices might be more suited, and maybe
a language unlike C might be even more so.

Greetings,
Maarten Hofman.

2005\08\16@030109 by Chen Xiao Fan

face
flavicon
face
I am not an C expert but I think device independent
does not really apply to "low end embed world". In this
world, C is not really device dependent. It is not even
platform independent for the same device. It is not
vendor independent as well.

Even in "high-end embed world", still C is not really
that device/platform/vendor independent. But let me
ask a question, are there any languages which are really
device/platform/vendor independent?

Hi-tech is doing a good job for their PICC for PIC16F
even though lots of the people complaining about PIC16F.
I have not looked at their PICC18 (some say it is
really good) and dsPICC (some say it is not quite
as good yet). However when I was using PICC, I never
used 90% of the libraries functions. Maybe it is
because that I was writing less than 2k words program.
ANSI conformance is sometimes silly if you read the
AVRLIBC list and they were discussing something like
sscanf which I doubt will be useful in most cases.
There are even people using C++ for AVR. And there
are versions of C for the tiny AVRs which does not
have RAMs (only 32 byte registers). Is it really
useful to put sscanf function for them?

As for C18 and C30, I think they look quite okay as well
in terms of so called ANSI conformance.

Maybe it is good that I am not from the PC programming
side to the PIC world so that I can appreciate more
of C for small MCUs. :) I am somewhat the reverse.
After programming some small C programs for PIC, I am
now learning to program small C program on the PC
side to talk to PIC. :)

Regards,
Xiaofan

{Original Message removed}

2005\08\16@081035 by olin piclist

face picon face
Maarten Hofman wrote:
> In fact, it is
> a glorified version of assembly, originally written for a specific
> type of processor. It has clear shortcuts (++ for "increment register"
> for example) meant to map directly on certain assembly instructions.

Another issue is that the designers of C were working on a Von Neuman
machine, and I don't thing gave any consideration whatsoever to C ever used
to code for a machine with multiple address spaces, each with its own
constraints and width.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...