What happened to TR 18037: Embedded C?

[Philipp Klaus Krause]

The latest draft is from 2006?

Is it dead? Will it be merged into C1X?

Philipp

 

[Walter Banks]

The latest draft is from 2006?

Is it dead? Will it be merged into C1X?

It was released as a ISO standard document around the
end of 2008. As far as I know there are no plans to merge
it into C1X but to keep it a separate document.

The latest draft is N1275 fall 2007

In the Markham meeting we agreed that TR18037
would be periodically revised and material for changes
would be saved and incorporated when appropriate.

There have been two papers since this TR was released.
N1351 a case for named processor space in
multiprocessor applications and N1386 describes the
additions needed to TR18037 to add named processor
space.

Regards,

w..

 

[Philipp Klaus Krause]

It was released as a ISO standard document around the
end of 2008. As far as I know there are no plans to merge
it into C1X but to keep it a separate document.

The latest draft is N1275 fall 2007

Thanks, I found it (why isn't it mentioned on the WG14 website?).

Do you know why the _Accum types only have 4 integral bits? Most
implementations of fixed-point math I've seen rather tends toward having
more integral than fractional bits or are at least balanced.

Philipp

 

[Thad Smith]

Walter Banks wrote:
[regarding fixed point C support]

For embedded systems implementations and non MAC based
processors, most implementations, the accum is either the fract
size plus a byte or double the fract size.

One of the appendix's in 18037 covers some of the issues
for selecting the implementation accum size. There is a strong
suggestion that the fract size and the fract size of the accum
be the same but the integral part of the accum is quite flexible.

I only have knowledge of two other systems with language support for fixed point
arithmetic:
1. PL/I
2. TI Pascal, via extended types.

Both implementations are over 20 years old, but in both cases the location of
the binary point was user-specified in the type declaration. It seems too
limiting to attempt to fit all with a single or few selection locations.

 

[Keith Thompson]

Walter Banks wrote:
[regarding fixed point C support]

For embedded systems implementations and non MAC based
processors, most implementations, the accum is either the fract
size plus a byte or double the fract size.

One of the appendix's in 18037 covers some of the issues
for selecting the implementation accum size. There is a strong
suggestion that the fract size and the fract size of the accum
be the same but the integral part of the accum is quite flexible.

I only have knowledge of two other systems with language support for
fixed point arithmetic:
1. PL/I
2. TI Pascal, via extended types.

Both implementations are over 20 years old, but in both cases the
location of the binary point was user-specified in the type
declaration. It seems too limiting to attempt to fit all with a
single or few selection locations.

The latest draft of TR 18037 is
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1169.pdf>.

Ada also has user-defined fixed-point types. A fixed-point type
definition specifies the range and the delta, for example:

type Fixed is delta 0.125 range -10.0 .. +10.0;

Ideally, the choice of resolution for a fixed-point type should
be up to the application, not to the implementation. But C
traditionally defines numeric types with sequences of keywords
(unsigned, signed, char, short, int, long, float, double, _Complex,
in various combinations) with the implementation determining the
characteristics of the type defined by each permitted combination.
For integer and floating-point types, this makes some sense, since
the types supported are typically those with hardware support.
For fixed-point types, though, support is typically in software;
a 16-bit type with 12 fraction bits is probably no more or less
difficult to implement than a 16-byt type with 11 or 13 fraction
bits. I suppose the authors of TR 18037 didn't want to define a
whole new mechanism and syntax.

I also wonder why the TR requires fixed-point types corresponding
to short, int, and long, but not to long long.

 

[Nick Keighley]

Walter Banks wrote:

[regarding fixed point C support]

For embedded systems implementations and non MAC based
processors, most implementations, the accum is either the fract
size plus a byte or double the fract size.

One of the appendix's in 18037 covers some of the issues
for selecting the implementation accum size. There is a strong
suggestion that the fract size and the fract size of the accum
be the same but the integral part of the accum is quite flexible.

I only have knowledge of two other systems with language support for fixed point
arithmetic:
1. PL/I
2. TI Pascal, via extended types.

Both implementations are over 20 years old, but in both cases the location of
the binary point was user-specified in the type declaration.  It seems too
limiting to attempt to fit all with a single or few selection locations.

CORAL-66 specified total bits and fraction bits in the declaration

http://www.xgc.com/manuals/xgc-c66-rm/c294.html#numerictypes

 

[Philipp Klaus Krause]

There is quite a bit of implementation flexibility to support
both hardware and application requirements. Support for
processors with a MAC is typically the _Accum size is
MAC accumulator size sometimes rounded up to a byte size.

For embedded systems implementations and non MAC based
processors, most implementations, the accum is either the fract
size plus a byte or double the fract size.

One of the appendix's in 18037 covers some of the issues
for selecting the implementation accum size. There is a strong
suggestion that the fract size and the fract size of the accum
be the same but the integral part of the accum is quite flexible.

And even that appendix has at least 8 integral bits for every type of
fixed-point number.
So far I've only seen two real-world fixed-point implementations: a
s15.16 in the pic backends of sdcc and a s9.6 one I wrote myself (I
needed at least 9 integral bits and wanted to myximize precision under
that condition).

Philipp

 

[Walter Banks]

And even that appendix has at least 8 integral bits for every type of
fixed-point number.
So far I've only seen two real-world fixed-point implementations: a
s15.16 in the pic backends of sdcc and a s9.6 one I wrote myself (I
needed at least 9 integral bits and wanted to myximize precision under
that condition).

I use 8:16 a lot in many embedded systems projects on 8 bit
micros and when the integral part needs to be larger than 8 bits
generally switch to an int. I store a lot of application constants
in fixed point.

The engine controllers use a 24bit processor with fractional math
capability that we use 24:24 accums.


Regards,

Walter..

 

[Flash Gordon]

I use 8:16 a lot in many embedded systems projects on 8 bit
micros and when the integral part needs to be larger than 8 bits
generally switch to an int. I store a lot of application constants
in fixed point.

The engine controllers use a 24bit processor with fractional math
capability that we use 24:24 accums.

I'm pretty sure one of the processors I used to use had support for
s0.15 which can be very useful for some types of work.

 

[Walter Banks]

I'm pretty sure one of the processors I used to use had support for
s0.15 which can be very useful for some types of work.

It probably also has a 8:16 or 16:16 as well. TR18037 separates
accums and fracts into two related types. accums have integral and
fract parts and there are fract types with only a (well) fract part

Regards,

Walter..

 

[Flash Gordon]

It probably also has a 8:16 or 16:16 as well.

I don't think it did. It was a 16 bit DSP, so definitely not 8:16 as it
did not have the concept of anything smaller than 16 bits.

I could be completely miss-remembering of course.

TR18037 separates
accums and fracts into two related types. accums have integral and
fract parts and there are fract types with only a (well) fract part

Ah well, in consider fract to be just a special case.

I would find the decimal equivalent very useful on the cost management
software I work on these days. Even more useful than decimal floating point!