Frank Shute wrote:
On Wed, Jun 11, 2008 at 05:06:49PM +0300, Heikki Suonsivu wrote:
Oops, sorry, I was not specific enough:

FreeBSD 4 or older NetBSD are no go:

The computer I am doing this is not old, it is otherwise brand new, but it uses an embedded cpu, a 486 clone as SoC without math. See, eBOX 2300SX. It is very low cost, runs on about 3W of power with CF card as mass memory, 128M, 3 USB2, serials, sound, etc, it has VESA form factor so you can attach it behind many LCD displays, etc. They have beefier models, but this one is cheapest and uses least power, latter of which is the more critical requirement for us.

We would like to use it for certain control applications. Linux works, has been tested, but requires patches (turn math emulation on, add support for built-in ethernet, bug workaround).

I don't know if this machine is going to be sited on an insecure
network or not. If it is, then you'll probably be using ssh. Without
a math co-proc to do the crypto, it will be horrendous. I don't even
know if ssh would work with an architecture without a maths unit.

You apparently do not use the source :), go and grep double and float from some of the most common programs you use (games, scientific stuff and crappy UI code excused).

> If it can't work with ssh, then you might be restricting your market.

ssh does not use any floating point for any crypto algorithm. Oh, openssh does use doubles, it prints some ratios in some places, such as how many percent of something has been transferred. It seems to be stirring random numbers as floating point non-exactness does is not a bother there, but that is not used past session init. There is no human-noticeable effect on normal ssh use.

I was one of the first guinea pigs for original ssh. We did have plenty of non-math cpus back then, and I did run ssh on non-fpu hardware until two years ago. We did run backups and configuration tasks over ssh on number of non-fpu computers acting as routers and other servers those days. Today's games might be different, but that is not what we do on these embedded computers...

I think you are punishing yourself unneccesarily by going with a
processor without maths. You restrict the software (both OS &
application) you can run.

Applications cannot tell the difference between math emulation and hardware from anything else than performance, so there is no code difference in application layer, and kernel does not do fp at all, other than trapping fpu instructions and emulating them on non-fpu hardware. Kernel itself does not do fp math.

I do not quite understand where this fear of non-fpu came from, as it made no practical difference just few years ago for anything but scientists in labs and intensive cad/graphics work. In particular I do not understand why people have an idea that everything uses floating point. Very few programs do heavy math processing, most common use is to double divide two longs to print out some statistics when program ends.

The problem with is that while FreeBSD 4 seemed to boot on it, it did not recognize any peripherals as they are new. Old OS's are not really what we want, this is not one-off but volume product, it will be internet-connected so we need bugfixes and we need support for latest chipsets on 802.11 cards etc.

There is another similar CPU, even slower and less power consuming, I do not remember the part number, I think it was about 100 MHz 486 without math as well. This was some manufacturer of microcontrollers.

Can't you find a manufacturer that makes something similar with a DX
instead? Or can you email this company and ask them how much it would
cost to run off X units with a 486DX rather than SX?

This is not 486, it is System-on-Chip thing. There are couple of very cheap SoCs, which do not have math, but performance is otherwise adequate for most applications. They are much faster than 486SX, by 5-10 times factor, so they are becoming popular on embedded devices.


_______________________________________________ mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to