d311b0f4c8
By adding `0.0` and not `0.0f` and by calling `fmod()` rather than
`fmodf()`, we were unintentionally coercing the value from a
`float` to a `double`.
This resulted in x86_64 assembler like this:
```
cvtss2sd %xmm0,%xmm0
cvtss2sd %xmm1,%xmm1
callq 403340 <fmod@plt>
cvtsd2ss %xmm0,%xmm0
```
which is now:
```
callq 403360 <fmodf@plt>
```
And for the `N_OP_equal` change:
```
cvtss2sd %xmm0,%xmm0
xorpd %xmm2,%xmm2
addsd %xmm2,%xmm0
cvtss2sd %xmm1,%xmm1
addsd %xmm2,%xmm1
xor %ecx,%ecx
ucomisd %xmm1,%xmm0
```
is now:
```
xorps %xmm2,%xmm2
addss %xmm2,%xmm0
addss %xmm2,%xmm1
xor %ecx,%ecx
ucomiss %xmm1,%xmm0
```
(Note `ss` rather than `sd`, along with the missing `cvtss2sd` calls.)
Maiko
This is the implementation of the Medley Interlisp virtual machine, for a byte-coded Lisp instruction set and some low-level functions for connecting with Lisp for access to display and disk etc. See the main Medley repository for Issues, Discussions, documents and more context.)
There are make file fragments that include all the flags and variables you have to set for each hardware/OS target.
- cd to the "bin" directory
- do
./makeright x
It will (attempt to) detect the OS-type and cpu-type, and put together the makefile parts that it needs. It will build in ../ostype.cputype-x (for the .o files) and ../ostype.cputype for the executables.
Development Platforms
We are developing on FreeBSD, Linux, macOS, and Solaris currently on arm, arm64, PowerPC, SPARC, x86, and x86_64 hardware.
We believe it will work on these platforms.
Fixes and improvements for additional platforms and hardware is welcome. Work is underway to run better on Windows.
In the past, Maiko ran on DOS. This may or may not still work.