On processors for D (Was: Re: std.date proposal)

[Walter Bright]

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.


> 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.)


> 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?


> 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.


> 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.

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



> 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.