What happened to TR 18037: Embedded C?
Philipp Klaus Krause
Is it dead? Will it be merged into C1X?
Philipp
Walter Banks
Philipp Klaus Krause wrote:
> 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..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com
Philipp Klaus Krause
>
> Philipp Klaus Krause wrote:
>
>> 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
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
Walter Banks
Philipp Klaus Krause wrote:
> > The latest draft is N1275 fall 2007
>
> 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.
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.
Regards,
Walter..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Thad Smith
[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.
--
Thad
Keith Thompson
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.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Nick Keighley
CORAL-66 specified total bits and fraction bits in the declaration
http://www.xgc.com/manuals/xgc-c66-rm/c294.html#numerictypes
Walter Banks
Keith Thompson wrote:
The latest draft of TR 18037 is
<. . . ./n1169.pdf>.
The latest draft is N1275
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1275.pdf>.
Ideally, the choice of resolution for a fixed-point type should
be up to the application, not to the implementation.
There is at least one C compiler that supports TI fixed point
DSP chips with selectable fract and integral parts. We did some
internal studies on this (including a test application selectable
library) and discovered that like ints there would be a size that
work for the application with a limited number of choices.
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.
In part that was true. Syntax and data formats dominated
discussions in the first few meetings.
I also wonder why the TR requires fixed-point types corresponding
to short, int, and long, but not to long long.
There was no real world example long long being needed in
our collective experience with fixed point implementation
and decided to not force it for a conforming implementations.
Some future review may include long long.
At the time the bulk of TR18037 was written most fixed point
was being used to support ISA's that had a MAC. There were
some applications in process control, more in audio processing
and a ton of cell phone based applications. We had a handful
of other applications between us that did not fall into those
categories.
The first three groups of applications sizes are either dominated
by the MAC size or fract plus a byte size. In the last group
fract and integral sizes equal to an int is most common.
Regards,
w..
Philipp Klaus Krause
>
> Philipp Klaus Krause wrote:
>
>>> The latest draft is N1275 fall 2007
>> 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.
>
> 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
Philipp Klaus Krause wrote:
> Walter Banks schrieb:
> > 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).
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.
Flash Gordon
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.
--
Flash Gordon
Walter Banks
Flash Gordon wrote:
> > 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.
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
Flash Gordon
>
> Flash Gordon wrote:
>
>>> 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.
>
> 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!
--
Flash Gordon