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
www.compactpc.com.tw, 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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"