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

[kris]

Walter Bright wrote:
[snip]
> 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?

Phobos does not suit everyone's ideal of a runtime library. Enforcing 
it's usage as part of the D language is no better than the tight 
coupling of the Java libraries that you've happily denigrated in the past.

There would be no problem with Phobos at all, if you'd avoid hooking it 
directly into the language. For example, TypeInfo recently changed to 
import std.string, which itself imports a slew of otherwise redundant code.

I truly hope you can see the ironic humour in that :)


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

I spend a lot of time with MCUs. The cost issue is not so much the 
register width, but the pin count. That is, a 32-bit device, perhaps 
with embedded FPU, is not really such a big cost issue (even for battery 
life, when you talk about static-cmos design at 10MHz to 100Mhz). But 
you need to feed it with something useful, which tends to increase the 
trace-count quite quickly (which then leads to other costs, etc, etc).

On the other hand, 8-bit designs are often implemented with as little as 
14 pins. That makes an entire system trivial to produce. Heck, there's a 
Hitachi MCU with 32bit registers on a 64pin package, just to keep the 
pin-count down (it can address only a few KB though). I'm rather 
familiar with that one, and can attest to it being able to execute 
realtime FFTs at 20Mhz, via FP emulation using its wide registers. 
Without those 32bit registers, that just wouldn't be feasible.

Once you get to PDA/Phone land, one is generally talking about 200+ pins 
on the MCU. Overall costs are up notably at that point, but then the 
devices support vast address spaces (now heading for the GB range). Such 
devices are now starting to gain dedicated 3D graphics coprocessors on 
the board (jeez!), so adding FPU support is surely not a cost issue there?

Still; at the both ends of the scale, it's quite likely that one would 
wind up facing a DSP-oriented design instead of a MCU+FPU design ~ 
simply because they're readily available and highly competitive (and 
with formidable libraries available).

I think the upshot is that one probably shouldn't /rely/ on FP support 
on MCUs, and thus a DateTime library targeted at such devices would be a 
trifle foolhardy to do so ~ especially when the alternatives are 
typically just fine?

I'm sure this has now gone completely off-topic;