Searching \ for '[OT]: 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/io/serial/spis.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
'[OT]: I say it is spinach and to hell with it!'
2005\08\15@202822 by John Nall

picon face
I have spent the afternoon going through the Microchip C30 user manual.  
This is truly an exciting task.  Never looked at C for a PIC before, but
figured it was time that I did.  Kind of a disappointment.  Wish I had
not done that.  Spoiled my day.

In the interests of full disclosure, let me say that I learned C from
the original  Kernighan and Ritchie book.  Not from a class, but from
sitting down with the book and figuring out how things worked.  I never
did agree with the "second edition" crap, in which they gave in to the
ANSI committee (my personal view on that is that "a camel is a horse
designed by a committee") but OK, that is the way it was, and I taught
the ANSI stuff to a whole lot of people in computer science classes.  
Never did get into C++, which I look upon about the same way I look upon
Starbucks coffee -- if you like it, fine, but I'll just stick with what
I have been drinking for years.   :-)  C++ is designed for people who
are not willing to be careful.

The point being -- is anyone ever going to stand up and say  the emperor
has no clothes?  This C30 stuff is not C.  It is related to the C
language, true.  But C is device independent   C30 is definitely not!  I
am not at all sure that the gulf between the Harvard architecture and
the Von Neumann architecture is not too wide to transverse, to be
honest.  I am all for getting a bit beyond assembly language (although I
think it should be required in kindergarten for all children) bu perhaps
we should not call it C if that is not what it is.  IMHO.  Flames
welcome.  (I have an abestos shield, in addition to being virtuous)..

John

2005\08\15@205313 by Sean Schouten

face picon face
LOL! Isn't it a fact that you have to use a somewhat limited amount of
the C-language to be able to program devices like the PICmicro family
of microcontrollers because of the difference in functionality and
available resources?

An 'EE'-friend of mine once told me that there was only one real good
compiler for PICmicro devices. I believe that he said that it was the
HI-TECH C-compiler. He did say that it was by far the most efficient
C-code compiler and I thought that he did mention something about
programming style but I am not entirely sure anymore.

He is a driven ANSI-C programmer that also uses "The Book" though. Not
that knowing that would be of much help or anything! :-)

Sean

2005\08\15@212514 by James Newton, Host

face picon face
> The point being -- is anyone ever going to stand up and say  
> the emperor has no clothes?  This C30 stuff is not C.  It is
> related to the C
> language, true.  But C is device independent   C30 is
> definitely not!

I guess my question would be how you would propose to bridge the gap between
the sort of IO, memory, etc... that C was designed for and the sort of IO,
memory, etc.. that the average PIC has?

Most of the device dependency, as far as I can see, is to deal with the
limitations and abilities of the devices. I'm not trying to say it can't be
done, but I'm curious to see if you have thoughts on how it could have been
done better.

---
James Newton: PICList webmaster/Admin
spam_OUTjamesnewtonTakeThisOuTspampiclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com



2005\08\15@214151 by Spehro Pefhany

picon face
At 08:28 PM 8/15/2005 -0400, you wrote:
{Quote hidden}

Okay. ;-)

Are you saying that you can't figure out how to make *most* of your
code device-independent and ANSI compliant with the C30 port of GCC?

Or are you just whining (BrE: whinging) about the bits that won't/can't be
like that?

Or, perhaps more reasonably, are you objecting on the basis that it allows
non-standard constructs (eg. case statements, IIRC) for no sufficiently
good reason?

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam@spam@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2005\08\15@214237 by John Nall

picon face
James Newton, Host wrote:

>>I guess my question would be how you would propose to bridge the gap between
>the sort of IO, memory, etc... that C was designed for and the sort of IO,
>memory, etc.. that the average PIC has?
>
>Most of the device dependency, as far as I can see, is to deal with the
>limitations and abilities of the devices. I'm not trying to say it can't be
>done, but I'm curious to see if you have thoughts on how it could have been
>done better.
>  
>

Yeah . . .a  lot easier to gripe about something than to propose
constructive alternatives, isn't it?  :-)  Gosh, I don't know.  It just
kind of threw me that this stuff was being presented as the C language,
and perhaps I over-reacted.  But of course Olin was correct.  And I will
have to give some thought to it.

Funny how my post started out as [OT[, then to nothing, then to [PIC],
then back to [OT] again.  What does it all mean???  Is this some sort of
vast right-wing conspiracy, just because I voted for Kerry???  :-)

John

2005\08\15@222239 by John Nall

picon face
Spehro Pefhany wrote:

> >Are you saying that you can't figure out how to make *most* of your
> code device-independent and ANSI compliant with the C30 port of GCC?

Nope.  I can program in assembly language and and very comfortable with
it, so I do not worry in the least bit about the C30 port of GCC.  That
is not at all the point.

> >Or are you just whining (BrE: whinging) about the bits that
> won't/can't be
> like that?

Use of the word "whining" projects an unfair picture, and kind of
implies that I am unhappy about it all.  I am not unhappy.  I am just
saying that what we have here is not the C language.  Fine.  I can live
with that.  But why not come right out and say it???

> Or, perhaps more reasonably, are you objecting on the basis that it
> allows
> non-standard constructs (eg. case statements, IIRC) for no sufficiently
> good reason?

Actually, I thought it was all quite reasonable. :-)  A bit of a thrust
toward windmills, true, but still reasonable.

John

2005\08\15@223313 by John Nall

picon face
Maarten Hofman wrote:

>> Modern ANSI C might be device independent to a certain extent.
>However, the C language was never intended to be such.
>
Well, we will probably just have to agree to disagree about that.

>> 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.
>  
>
Irrelevant and immaterial.  The C language is and was defined by the
book "The C Programming Language" by Kernighan and Ritchie.  The only
concession made to architecture was to the size of the word.  Most
certainly I will agree that they developed the language on a machine
which had a specific architecture (actually, I believe they had several
machines, but the architectures were similar -- at any rate, all were
Von Neumann machines).  So what?

>> 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.
>  
>
You are agreeing with Olin, and I agree with Olin also.  So we all come
to the same point, do we not??  :-)

John

2005\08\15@225041 by Aaron

picon face
My, my, what happened to the tame piclist of of last week? :)

First it was the 'which PIC is best for beginners debate' and now we
have compiler wars... all we need is a newbie to get offended before we
call it a day.  :)

Aaron


2005\08\15@232126 by Spehro Pefhany

picon face
At 10:22 PM 8/15/2005 -0400, you wrote:
>Spehro Pefhany wrote:
>
>> >Are you saying that you can't figure out how to make *most* of your
>>code device-independent and ANSI compliant with the C30 port of GCC?
>
>Nope.  I can program in assembly language and and very comfortable with
>it, so I do not worry in the least bit about the C30 port of GCC.  That is
>not at all the point.

Well, I think this is the *main* point to using C on small micros. To make a
good portion of the code standard, so it can be directly used or quickly ported
to other micros in the same or different families. Thus many of the same
routines
can be used on an 8051, an AVR, a PIC16, a PIC18 and an ARM. I find this
rather
useful myself. It is not as optimal a use of processor as assembly, of
course, in
general, but that is only one factor among many. Some (or all, in the extreme
case) of what's not ANSI-ish C may be written in non-standard C, in
non-portable
assembly, or whatever, as suits the problem domain.


>> >Or are you just whining (BrE: whinging) about the bits that won't/can't be
>>like that?
>
>Use of the word "whining" projects an unfair picture, and kind of implies
>that I am unhappy about it all.  I am not unhappy.  I am just saying that
>what we have here is not the C language.  Fine.  I can live with
>that.  But why not come right out and say it???

There are probably no compilers that are completely compliant with the current
standard (ISO/IEC 9899:1999 (E)). In a sense, then, there is no such thing
as a "real" C compiler. But such a
degree of anality, while encouraged in such forums as comp.lang.c is not
really that useful to working
engineers who are designing real products.

There are something like 17 pages in the C30 manual illustrating the
differences between ANSI C and
C30.  The current C standard is 550+ pages.  Therefore, it's clearly 97%
compliant. ;-)   Is this not enough
to be useful?

Is there anything in particular that caused you to throw up your hands and
say "Hey, this isn't C!"?

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffspamKILLspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2005\08\16@025833 by Lindy Mayfield

flavicon
face
I think you make very good points.  This is one reason I (still beginner/hobbyist with microcontrollers) decided to stay with assembler and not move to C, or use Basic unless necessary for the Basic stamp.

This has been a question in my mind when I first looked at HLL's for a Pic:  How would one design the C language (or any other) "properly" in terms of what you refer to?  Like portability, device independence, etc?  How do you get around the fact that you have to deal so closely with I/O pins, hardware modules like PWM, etc. which change so much from chip to chip?

I'm not so sure that it is the Harvard vs. von Neumann that is the problem, but the vast differences in the I/O peripherals.  I mean, if C is made to be portable, how would one make it so the same program works on a 12F675 and a 16F877?  What is the difference between this and a C program that compiles and runs on UNIX, Windows and an MVS mainframe?  (Lots of compiler IFDEFS?)  

Just thinking out loud.  I find this a fascinating subject to think about.

-Lindy


{Original Message removed}

2005\08\16@033225 by Wouter van Ooijen

face picon face
> This has been a question in my mind when I first looked at
> HLL's for a Pic:  How would one design the C language (or any
> other) "properly" in terms of what you refer to?

A few issues:
- C assumes that the 'natural' integer size of the machine is (at least)
16 bits. This does not map well to 8-bit chips. (Anyone seen a C
compiler for 4-bit chips??)
- in C a bit has no address, and there are no bit variables. this makes
it hard to use (PIC) bit instructions efficiently, or to use the limited
memory on a small (PIC) chip efficiently
- C (almost) assumes a single flat address space. this does not map well
to the split code/eeprom/ram space of a PIC, to memory banking, or to
the various address spaces of a 8051. It was also troublesome on the
8086 segmented memory model.
- C supports recursion, so it assumes some form of stack (either
hardware or software). this does not map well to a 12/14bit core PIC,
and is still painfull on the early 18F's (less so on the modern 18F's?).
Note that recursion makes it impossible for the compiler to predict the
stack size that is needed, so in an embedded system it is often
disallowed anyway.

There are lots of other issues that can be solved with libaries, macro's
etc. for instance: there should be an integer type that is at least
0..255, but maps to the 'best' machine type. This could be a byte on a
PIC, but on an ARM probably a 32-bit word.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\08\16@043906 by Alan B. Pearce

face picon face
>Use of the word "whining" projects an unfair picture, and kind
>of implies that I am unhappy about it all.  I am not unhappy.
>I am just saying that what we have here is not the C language.
>Fine.  I can live with that.

>But why not come right out and say it???

Could you live with the fact it is pointed out that it is C ported (by your
own admission) to something else, and they come out and say that by calling
it C30?

2005\08\16@061909 by Gerhard Fiedler

picon face
John Nall wrote:

> The point being -- is anyone ever going to stand up and say  the emperor
> has no clothes?  This C30 stuff is not C.  It is related to the C
> language, true.  But C is device independent   C30 is definitely not!  

Maybe that's why it's called C30 and not "ANSI C".

But for any discussion that goes beyond flames and rants, you probably
should make the effort and spell out what exactly you don't like, and why.

I don't know Microchip's C30, but I know (and use, and like) HiTech's PICC
and PICC-18. I don't have a problem calling my programs "C programs".

Gerhard

2005\08\16@082053 by John Nall

picon face
Alan B. Pearce wrote:

>> Could you live with the fact it is pointed out that it is C ported (by your
>own admission) to something else, and they come out and say that by calling
>it C30?
>  
>

Yes, I can live with that.  Good point.  :-)  And I will not beat this
horse any more.  Over and out.

John


2005\08\16@083333 by olin piclist

face picon face
Wouter van Ooijen wrote:
> for instance: there should be an integer type that is at least
> 0..255, but maps to the 'best' machine type. This could be a byte on a
> PIC, but on an ARM probably a 32-bit word.

This is something I added to my source to source translator long ago.  After
reading the back end configuration file that defines what the target
processor and language can do, it creates various data type symbols.  For
the Pascal input language it creates a set of data types called
SYS_INT_CONVxx_T, where XX is the minimum bits you need in an integer.  This
then maps to the integer of at least that size that is most convenient from
the target system's point of view.  What you are asking for above is exactly
my SYS_INT_CONV8_T.  There are also other data types, like SYS_INT_MINxx_T
which map to the smallest target integer at least xx bits wide.


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

2005\08\16@100356 by Wouter van Ooijen

face picon face
> > for instance: there should be an integer type that is at least
> > 0..255, but maps to the 'best' machine type. This could be
> a byte on a
> > PIC, but on an ARM probably a 32-bit word.
>
> This is something I added to my source to source translator
> long ago

Every serious C development environment has something like this. But
note that it still restricts you to the types that C happens to have
choosen. On a system with 8,16,32 and 64 bit integers there is no way to
get an economic 24-bit integer. Check Ada for a more flexible way to
specify integers. But Ada is a much moer complex language, and has never
realy gained the momentum in the embedded world.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


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