I say it is spinach . . .
Gerhard Fiedler email (remove spam text)
William ChopsWestfield wrote:
>> Only C construct -- that I can think of -- having an issue with
>> CPU architecture is pointers.
> I think I agree.
It has to do, but it's not necessarily an issue. At least in working with
the HiTech C compilers, I don't have a problem at all with the separate
memory spaces. A "pointer to non-const" can't point to const variables --
that's as it should be. A "pointer to const" can point to both const and
non-const variables -- that's also as it should be. In the use of the
pointers, you're pretty much shielded from the memory architecture issues.
Besides, with a typical C implementation, from a programmer's POV you do
have (at least) three memory spaces to take into consideration, and you
better know how they are related and how they are different -- and that's
on all memory architectures. There's the program memory, the stack memory
and the heap memory. There are operating systems and C implementations for
Neumann machines that won't allow a heap or stack pointer to access program
memory. So even on traditional Neumann architectures, there's often not a
single memory space. Also, since the C language doesn't provide any useful
means of altering its execution code at runtime, there's really no point in
accessing program memory -- from a /language/ POV.
My conclusion: the memory architecture may or may not make implementation
easier or more difficult, but it's not an issue with C pointers. A C
programmer doesn't work with a Neumann memory model, she works with
separate memory spaces anyway, and you always need to have a basic
understanding how the different language memory spaces are implemented on
the specific processor/operating system you are working with.
> the other issue that usually comes up that it is DESIRABLE to have a
> single-bit-wide data type in many embedded applications. While adding
> such a capability to a compiler tends to be less objectionable than
> doing weird things with existing parts of the language, it can still be
> disconcerting to language purists...
There are the bitfields, but they are not really bit datatypes. I think
most C compilers for small processors (where you may want to use bits
rather than bytes as flags, or where bits may be more efficient than bytes)
add some sort of bit type. Unluckily, usually not with pointer support.
(For my part, I don't really care much if language purists object to this
-- I just use them, and complain about lack of pointer support :)
Wouter van Ooijen wrote:
> How about recursion on a CPU where the only (effective) addressing mode
> is absolute memory addrresses?
I think this is the only /C language/ feature that's missing from most
compilers. OTOH it's not that big of an issue, because I've never seen the
need for recursion on such a small system. And I tend to think that there's
not only no need, but it's pretty dangerous to use recursion in small
embedded systems. Recursions are usually used where you do /not/ want to
(or can't) predict how deep the codes goes until it reaches the end
condition -- that is, where you don't want to or can't reformulate the
solution in a non-recursive loop. In embedded systems, I think you /have/
to analyze the problem so that you have a non-recursive solution with a
defined maximum depth -- because your resources are limited, and you can't
just abort the program with an "out of memory" message to the user in case
the solution takes more cycles than you have memory for, and because
usually you do have time constraints for every task.
Now I may just rationalize why I don't need what I don't have, but I really
think I would seriously try to avoid recursion even if I had it available.
In reply to: <firstname.lastname@example.org>
See also: www.piclist.com/techref/io/serial/spis.htm?key=spi
You must be a member of the
piclist mailing list
(not only a www.piclist.com member) to post to the