On Sun, Jul 16, 2017 at 7:26 AM, Alexander Burger <a...@software-lab.de> wrote: > On Sat, Jul 15, 2017 at 03:02:02PM -0400, Matt Wilbur wrote: >> Correct. I am working on a project that uses a MIPS processo embedded >> ... >> I need the 64-bit PicoLisp, but MIPS isn't one of the >> architectures currently supported. > > Now I understand. > >> I started to look at how things >> are done for ARM and intel, but don't have the time right now to >> properly add MIPS. > > This is the right place. A MIPS port would probably be similar to the arm64 > and > ppc64 versions. But it is indeed a nasty piece of work. Each of the existing > ports took me several weeks. Funny thing is that the most tedious part was > always the floating point support (despite PicoLisp does not have floats in > the > language, it must support them on the VM level for 'native' calls).
I would very much like to take a crack at as I think it would be a great learning experience. At a first glance the code that generates the assembly looks very reminiscent of some of the old assemblers written in Forth I once admired. I am by no means a MIPS guru but I have enough resources I think I can figure stuff out. >> So, I got the 64-bit PicoLisp compiled in emulator mode, after >> cross-compiling sysdefs, capturing the output in a text file, and then >> using that output in places where the output from sysdefs was read via >> a pipe. > > OK, good. The drawback with emu is the slow execution speed though. > > >> I had assumed (perhaps incorrectly) that, using emu, VM bytecode was >> created on the fly and that it gets "executed" > > The bytecodes (if we may call 16-bit words "bytes") are created at build time, > as you will have noticed, in the generated C source files. > > >> I am completely open to the idea that I am being completely wrong >> headed about something. > > Not wrong at all. The problem is only the missing MIPS port ;) > > ♪♫ Alex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
