On processors for D

[Georg Wrede]

Walter Bright wrote:
> Georg Wrede wrote:
>> Walter Bright wrote:
>>
>>> At the start that D wasn't going to accommodate 16 bit processors for
>>> very good reasons, there are 32 bit processors in wide use in the 
>>> embedded market that do not have hardware floating point. There is no
>>> reason to gratuitously not run on those systems.
>>
>> Ok, that was exactly the answer I thought I'd get.
>>
>> Currently, this issue is not entirely foreign to me. I'm delivering a 
>> HW + SW solution to a manufacturer of plastics processing machines, 
>> where my solution will supervise the process and alert an operator 
>> whenever the machine "wants hand-holding".
>>
>> For that purpose, the choice is between an 8-bit and a 16-bit 
>> processor. Very probably a PIC. (So no D here. :-), I'll end up doing 
>> it in C.)
> 
> So, you're not even using a 32 bit processor, but a 16 bit design. I 
> know for a fact that there are *new* embedded systems designs going on 
> using 32 bit processors that don't have FPUs.

True. I understand they are targeted to big manufacturers, who know 
exactly the use, and do large production runs. And where ASICs would be 
too expensive, considering the width of the task. (Set top boxes, 
automotive control subsystems, telecomms network equipment, etc.)

Making significant inroads to those areas, however, may be asking for 
too much. The manufacturers are big corporations, they have an 
established (and massive) infrastructure already in place, and that is 
either directly or indirectly relying on C, whose track record is 
unparallelled.

So for them to even glimpse at D, D would have to offer something 
significantly better for that domain. (Which (I'm sorry) I don't 
currently see.)

>> Now, considering Moore, and the fact that the 80387 math coprocessor 
>> didn't have all too many transistors, the marginal price of math is 
>> plummeting. Especially compared with the minimum number of transistors 
>> needed for a (general purpose) 32-bit CPU.
> 
> So why are you using a 16 bit design? I can guess - cost. And that's why 
> embedded systems for 32 bit processors often don't have FPUs. Cost, 
> where even a few cents matter. (Also power consumption.)

The task is simple enough for an 8-bit processor to handle just fine. 
(In my case, the thing is mains-operated, and the CPU cost is negligible 
compared with the rest of the delivery, so my reason is just easier 
programming.)

>> Also, since the purveyors of 32-bit processors are keen on showing the 
>> ease of use and versatility of their processors, it is likely that 
>> even if math is not on the chip, they at least deliver suitable 
>> libraries to emulate that in software.
> 
> I have such a library (needed for the DOS-32 support). Although it works 
> fine, it is 100 times slower than hardware floating point. Embedded CPUs 
> are often strapped for speed, so why gratuitously require floating point?

It should be much slower. Otherwise FPUs would not be popular. :-)

Otoh, it doesn't slow down anything else, so in many cases the total 
performance hit is minor. And a good compiler/linker would in any case 
indluce only the actually used routines. You may even use this in 
combination with lookup tables, if profiling results show the need.

(Why use FP hardware or libraries at all, is the same kind of question 
as why use automatic memory management! Right? One can get by without, 
but if it's there, why not use it.)

>> Now, in the former case, math is either on-chip, or included in the 
>> libraries. In the latter, either we don't use math, or we make (or 
>> acquire) the necessary functions from other sources.
> 
> Or design out unnecessary uses of floating point.

For speed, of course. But for size, with D, it's not that simple. With 
the current size of "Hello World" (if done without C's printf), a basic 
FP library starts to feel small.

>> The second use case worries me. (Possibly unduely?) D not being 
>> entirely decoupled from Phobos, at least creates an illusion of 
>> potential problems for "from-scratch" SW development for embedded HW.
> 
> Phobos doesn't require floating point support from the processor unless 
> one actually uses floating point in the application code.

Turbo Pascal has had this since the '80s. You could turn a switch so 
that it automatically uses the FP library if float was used and the 
runtime computer didn't have an FPU.

> I also really don't understand why anyone using D would require not 
> using Phobos. What's the problem?

I admit this is a "feelings based" thing with most people I've talked 
with. It seems that on embedded platforms, many expect to write all the 
needed code themselves. It's also felt (possibly unduely??) that Phobos 
(or whatever general Win+*nix standard library) is mostly useless in 
embedded applications.

Of course, this may also be due to lack of information on their side?

>> We do have to remember the reasons leading to choosing a 32-bit 
>> processor in the first place: if the process to be cotrolled is too 
>> complicated or otherwise needs more power than a 16-bit CPU can 
>> deliver, only then should one choose a 32-bit CPU. Now, at that time, 
>> it is likely that requirements for RAM, address space, speed, and 
>> other things are big enough that the inclusion of math (in HW or 
>> library) becomes minor.
> 
> All I can say is I posed the same question to embedded systems people 
> using 32 bit CPUs sans FPU, and they tell me the costs are not minor - 
> either in money or power consumption.

The world is going towards an increasing number of small and midsize 
companies entering the embedded arena. They typically would want to work 
with a single architecture, for obvious reasons. A CPU that contains 
math hardware which can be turned off when not needed (as well as other 
systems that can be powered off), seems to answer that kind of needs. I 
increasingly see CPU designers understanding this trend.

---

To give a parallell (to explain my view here): There are many Linux 
distributions that are compiled with 386 as target. At the same time, 
their specs for memory, clock speed, etc. _in_practice_ rule out any 
machine not using recent Intel processors. I see this as a joke.

Call this inconsistent specs. I'm discussing here so D would avoid this 
kind of inconsistencies.

Insisting on not needing hardware FP is ok. But to legitimize that, one 
has to cater to scarce resources in other areas too. Conversely, not 
genuinely making the language usable in smaller environments, makes 
striving to independence of FPU not worth the effort and inconvenience.