David Brown wrote:

David,

ISO/IEC 18037 supports named address spaces and user defined
address spaces. Named address spaces allows direct access to the
processor memory space that is used in some DSP's for mac operations
User defined address space is a little more complex but allows
positioning of mac specific buffering.

Byte Craft found that the data types and better access
to the processors native address space separated a lot of the
implementation specific extensions and intrinsics. My experience
in automotive applications was it refocused the compiler on
mac code generation and the application on algorithms.

Retargeting the automotive code to a different execution platform
in our case required little more than redefining the processor specific
address space.

Our experience is similar to that of other compiler companies
that have implemented ISO/IEC 18037

Regards,

--
Walter Banks
Byte Craft Limited
Tel. (519) 888-6911
http://www.bytecraft.com
walter@bytecraft.com

Mark Borgerson wrote:

Most embedded systems compilers have extensions that
support processor register access. A lot of the compilers
were implemented from hosted compilers as a base and the
initial startup code was written before they added support
for processor access. The example startup has often been
this early code. My point is that it can be done in C.

In our case the first C compiler was written for the C6805
and that was based on a 6805 mistral compiler we had written
a few years earlier. Our initial startup code was written
in C on a compiler that would support it.

register_sp SP;

SP = int_value;

w..

"linnix" <me@linnix.info-for.us> wrote in message
news:cb7dfc98-3ba4-4a0c-981d-18ddf8057370@e67g2000hsa.googlegroups.com...
Simplest reason in the world. The development package didn't provide them.
The app notes specifically said to initialize RAM, set the stack pointer, a
couple of other things (ensure interrupts were disabled, I think), then jump
to _main. Provided a couple of examples of how to do it, but did not
provide them.

- Bill

"Grant Edwards" <grante@visi.com> wrote in message
news:3qWdnbveM7gCsJPVnZ2dnUVZ_rjinZ2d@visi...
Most do these days.

Very often true.

- Bill

Walter Banks wrote:
Those I use don't, at least if you don't count inline assembler macros.

What you're doing here is writing assembly with C syntax. It relies upon
a heavily non-standard language extension, and makes assumptions about
how the compiler behaves (you don't want the compiler to use the stack
before your SP assignment, do you?). So instead of writing assembly in
C, I prefer using the real thing.

But a program doesn't need much assembler code. Actually, one of my
recent ones has exactly two lines of assembler: the SP assignment,
followed by a call to 'main'. But, to be fair, this program is preceded
by a boot loader which is 90% assembler, and leaves the processor in a
sane state: annoying registers and BSS segment zeroed, compiler startup
code often assumes neither.


Stefan

Walter Banks wrote:
The named address spaces and other ISO/IEC 18037 changes will also be
welcome additions to C compilers. I still don't see that the changes
will eliminate all the intrinsics and extensions in some of the dsp code
I've seen - but I haven't actually tried it in practice. Obviously you
know a lot more that I about the new types and other enhancements to C,
and what can be done with them - I've merely read a couple of spec's.

Stefan Reuther wrote:

I actually agree with you it is very low level C. The purpose of ISO/IEC
18037 was to define the low level syntax. Most start up code is very processor
family specific. Writting start up code in C makes good use of C's
optimization like the branch/jump to main.

w..

On Apr 23, 7:27�pm, Walter Banks <wal...@bytecraft.com> wrote:
Yes, thats what he always does! He can then claim his compiler can
beat assembler for speed,code size ect. To Walter if it looks Cish,
ends in a semicolon and his compiler can change it into machine code
then its C.


Whats to optimise? Why bother optimising a one time instruction?

Sometimes I think you'll say anything to sell a compiler.

cbarn24050@aol.com wrote:

The serious answer is some initialization on some processors
requires memory management that is easier for the compiler to
do.

I think my comments on startup code would apply to quite a
few embedded compilers.

w..

cbarn24050@aol.com wrote:
Why would you bother optimising a traditional call to main into a jump?
On some targets (in particular, several that Bytecraft target), the
saved stack space is significant - and even the couple of saved flash
bytes is worth doing (given the negligible cost of the compiler's effort).

There is also the question of why would one bother to write code that
you know is less than optimal, if it is just as easy to write better code?

On Apr 23, 10:03Â*pm, David Brown
<david.br...@hesbynett.removethisbit.no> wrote:
If it is on your project you are allready are allready up a certain
creek without a paddle. In any event you wouldnt use a "traditional"
ie a C type call to main from startup so stack saveing would be
minimal.

When C runs on embedded systems processors that are not hosted main should never return.

w..

On Apr 23, 9:38�pm, Walter Banks <wal...@bytecraft.com> wrote:
Any hope of an example that demonstates your point?

Walter Banks wrote:
In other words you seized a user available identifier, register_sp,
and then recognized that in the code to accept an int_value and
initialize the stack pointer. This is not C, but an extension.
The only thing wrong with that is that it is not marked as an
extension. If the mechanism is also used to read the SP the above
declaration should mark it as volatile. I think it would be better
to use a name reserved for the implementation, such as
__register_sp.

I am not objecting to extensions. However I believe they should
minimize any effects on standard C.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


** Posted from http://www.teranews.com **

"Walter Banks" <walter@bytecraft.com> wrote in message
news:480FAC36.E382E22B@bytecraft.com...
Usually, no. But it's a good idea to make sure the system does something
reasonable if it does.

I said before that I wrote init routines to "jump" to _main. And I have,
when it had to be that way. But whenever I've had a choice, I've actually
pushed the address of my restart routine onto the stack first then done the
jump. If _main DOES return, the machine reboots. In one case I raised the
error flag on the system and set a code in the status LEDs when _main
returned.

- Bill

Walter Banks wrote:
What if the programmer puts (as he should) a return into main?
This means you have to stack an address for that return (possibly
the address of main).

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


** Posted from http://www.teranews.com **

cbarn24050@aol.com wrote:
First off, Walter writes compilers and their associated libraries -
saving a few bytes of stack space there means savings for all his users.
We are not talking about individual projects here.

Secondly, some processors have small fixed-size hardware stacks (small
PIC's and AVR Tiny's are examples). For such devices, a single
unnecessary "call" can waste a third of your stack resources.

CBFalconer wrote:
Personally, I prefer to avoid extra underscores - they make the code
look ugly. But it's important that it is possible (through compiler
flags and/or choice of include files) to disable any extensions not
marked with double underscores.

On Apr 22, 3:50*am, Lax <Lax.Cla...@gmail.com> wrote:
Can't interface with with external hardware without assembly.

On Tue, 22 Apr 2008 01:50:31 -0700 (PDT), Lax <Lax.Clarke@gmail.com>
wrote:

Why do you ask this ?

Do you expect that you could work with embedded systems without
learning anything about the hardware architecture and the processor
instruction set ?

Most embedded project could be written completely in C except for the
initialization code, possibly some interrupt preamble code, OS task
switching and the use of some processor specific special instructions.
In most cases this would be 1-2 pages of assembler code.

However, if you are developing embedded applications in C or in other
high level languages, you really have to understand what machine
instructions are generated and what resources are needed for a
specific construction.

Also when debugging a program, understanding the instruction set (and
assembler) will help a lot.

Paul