[PATCH]:erts/emulator/beam/erl_time_sup.c

[Per Hedeland]

Matthias Lang <matthias@REDACTED> wrote:
>
>Secondly, it introduces more floating point code into areas of Erlang
>which aren't directly related to floating point. For desktop PCs, this
>isn't a problem since they all have CPUs with hardware floating point
>support. But most embedded CPUs don't have that, so at best it's a
>performance hit (if the OS has floating point emulation) and at worst
>it causes a crash (I think this is the case for VxWorks).
>
>Aside: a quick grep of the sources showed that the GC and memory
>       allocation code has floating point code in it now. What do
>       the VxWorks users do? Are there any left?

There are a couple of us around here (still at R7 for this application
though) - and while I'm not a fan of VxWorks (wasn't our choice:-), I
think you're a bit unfair - it includes fully usable SW FP emulation for
most supported architectures AFAIK.

Of course in our case, the company we collaborate with on this, which
provides both BSP and basic VxWorks setup, had managed to neither
properly initialize the HW FP that was actually there in the CPU (MIPS
4000-ish) nor activate the FP emulation - this didn't cause a crash in
our case, but most FP operations and functions just returned 0.0, which
had some "interesting" effects. (Well we did get crashes when we tried
to change that...)

And to get somewhat back on-topic for the list, you can now all make a
note in your calendars that Erlang (with some very minor porting tweaks)
runs just fine on VxWorks on MIPS - though I wouldn't be surprised if
we're the only ones in the world that care.:-)

--Per Hedeland
per@REDACTED