6fe335b9e9
bug caused by this instruction: fmove.l fp0,d0 problem was caused by a conflict between the fpu emulator (softfloat) and the compiler. the emulator implemented this as a purely arithmetic move & conversion, but the compiler assumed that the result could be interpreted as a logical (ie unsigned) conversion. rightly or wrongly. for example, if fp0 contained the value 2576980377.0 which is unsigned integer -1717987328 the emulator would treat this as an integer overflow and move 0x7fffffff (INT_MAX) into d0. The complier on the other hand would assume that d0 contained 2576980377 (the unsigned value). I don't know which is correct, but this is my fix for the time being. |
||
---|---|---|
.. | ||
emu | ||
include | ||
libsys | ||
tests | ||
boot.s | ||
build-pkg.lua | ||
build-tools.lua | ||
descr | ||
README |
# $Source: /cvsroot/tack/Ack/plat/linux386/README,v $ # $State: Exp $ # $Revision: 1.2 $ The linux386 platform ===================== linux386 is an i386-based BSP that produces Linux ELF executables. This port only implements a very limited number of system calls; basically, just enough to make the demo apps run. Adding more is easy, but there are some subtleties that require more thought. The port should be considered only in proof-of-concept stage right now. Important note: you *can't* link access ELF shared libraries from these executables. In other words, you have to all your work from inside ACK. IEEE floating point is available, but requires an FPU. The executables are generated with aelfslod and are extremely simple; there's one rwx ELF section which contains all the application's code and data. This is not optimal, but it does work. Bugs ==== isatty() is a stub and always returns 0. Example command line ==================== ack -mlinux386 -O -o linux386.exe examples/paranoia.c The file linux386.exe can then be run on a i386 Linux machine (or on an emulation thereof). David Given dg@cowlark.com