Prev: What happened to computer architecture (and comp.arch?)
Next: Parallel huffman encoding and decoding algorithm/idea by Skybuck for sale !
From: nmm1 on 20 Sep 2009 06:39
In article <ggtgp-7041FB.01012620092009(a)netnews.asp.att.net>,
Brett Davis <ggtgp(a)yahoo.com> wrote:
>
>As for the half software FPU idea, not a fan of it. Mostly because it
>has a tiny niche between no FPU and the microcoded FPU. Not a big enough
>market to pay for the hardware design, much less the compiler support.

You have completely misunderstood my proposal, which was (effectively)
to make the firmware primitives accessible to software, and move the
controlling logic into software. It also wasn't intended for a
particular niche, but to be almost universal.

In any case, firmware-based floating-point implementations are rare
nowadays - full-blown hardware ones, sometimes supported by (yuck)
software interrupts are the norm. Inter alia, my proposal would
including abolishing interrupts for floating-point fixup.


Regards,
Nick Maclaren.
From: Brett Davis on 20 Sep 2009 18:59
In article <h950ps$9ds$1(a)smaug.linux.pwf.cam.ac.uk>, nmm1(a)cam.ac.uk
wrote:

> In article <ggtgp-7041FB.01012620092009(a)netnews.asp.att.net>,
> Brett Davis <ggtgp(a)yahoo.com> wrote:
> >
> >As for the half software FPU idea, not a fan of it. Mostly because it
> >has a tiny niche between no FPU and the microcoded FPU. Not a big enough
> >market to pay for the hardware design, much less the compiler support.
>
> You have completely misunderstood my proposal, which was (effectively)
> to make the firmware primitives accessible to software, and move the
> controlling logic into software. It also wasn't intended for a
> particular niche, but to be almost universal.

Your intentions of universality do not mesh with the actual niche
economics, and the profit and loss tradeoff this would represent for the
first mover to actually implement this.

Pipelining floating point code is a big part of what I do for a living
as a software engineer, so I have a clear idea of where this fits in the
market, and I am afraid that market may be nonexistent.

Take a standard four way unrolled loop implemented as fixed point,
float, and firmware. The fixed point loop may be 20 instructions and
give four results, the float version also is 20 instructions and gives
four results. The firmware version is ~100 instructions and gives four
results.

If you think that is bad, now do a branchy code version where each
if/then/else has a single floating point operation in it. For fixed and
float you have 20 branches and 20 operations, for firmware you have
100's of instructions and ~1000 cycles blown in stalls.

The code bloat is outrageous and the performance is pathetic.

The Playstation One and the Nintendo handhelds do not have FPU units,
that did not stop us from writing lots of fully 3D games. We just used
lots of fixed point code.

There are a few math operations where fixed point gave gibberish
results, in those cases we implemented a software FPU similar to your
firmware proposal. You put the mantissa in one register and the fract in
another, and use ordinary integer math to generate a result with the
needed accuracy. Horribly slow, but it was 0.1% of the code and 1% of
the cycle time. Adding a real firmware assist would not have been cost
effective.

> In any case, firmware-based floating-point implementations are rare
> nowadays - full-blown hardware ones, sometimes supported by (yuck)
> software interrupts are the norm. Inter alia, my proposal would
> including abolishing interrupts for floating-point fixup.

None of the embedded FPU chips I know of will ever invoke a software
interrupt to fix up a float number. They all implement the standard
subset of IEEE float with simplified semantics.

The full IEEE float spec is an outdated grandiose kitchen sink. An easy
straw man to rally against, but irrelevant.

> Regards,
> Nick Maclaren.
From: nmm1 on 21 Sep 2009 03:14
In article <ggtgp-E10513.17593120092009(a)netnews.asp.att.net>,
Brett Davis <ggtgp(a)yahoo.com> wrote:
>
>> >As for the half software FPU idea, not a fan of it. Mostly because it
>> >has a tiny niche between no FPU and the microcoded FPU. Not a big enough
>> >market to pay for the hardware design, much less the compiler support.
>>
>> You have completely misunderstood my proposal, which was (effectively)
>> to make the firmware primitives accessible to software, and move the
>> controlling logic into software. It also wasn't intended for a
>> particular niche, but to be almost universal.
>
>Your intentions of universality do not mesh with the actual niche
>economics, and the profit and loss tradeoff this would represent for the
>first mover to actually implement this.

Please read what I said, and don't read things I didn't say into it.

This is comp.arch, and I was talking about the engineering aspects.
What I should like to see, and what the assorted benchmarketers,
politicians, bean-counters, money-grubbers, gutter press and what
not ensure that we are give, are two entirely different things.


Regards,
Nick Maclaren.
First  |  Prev  | 
Pages: 1 2 3 4 5 6 7 8
Prev: What happened to computer architecture (and comp.arch?)
Next: Parallel huffman encoding and decoding algorithm/idea by Skybuck for sale !