Thanks Alex....a friend of mine recently made a RISC V processor using fpga and it got me intrigued by the whole FPGA thing ...perhaps a picolisp machine may be possible :) ... .this would require some digesting for me...
Looks like there may be other folks who may be interested in the llvm approach....mostly to get it running on other platforms....I am hoping to run it on windows....perhaps by linking against some cross platform posix.....I was wondering if I could offer to help in anyway to expedite :) Regards Kashyap On Fri, Feb 14, 2020, 12:00 PM Alexander Burger <a...@software-lab.de> wrote: > Hi Kashyap, > > > Hey Alex, I did a quick comparison of a couple of .l files (gc.l and > > flow.l) between pil21 and the current src64 files. I was expecting the > > assembly files to not have much changes - I mean, in theory, only an > > arch/llvm.l and perhaps minor tweaks in some more file should have been > > enough right? > > Yes, in theory absolutely correct :) > > However, the LLVM virtual machine is completely different from the Pil64 > machine. > > The latter is a virtual traditional CPU, with a well-defined set of > registers > (see https://software-lab.de/doc64/asm). Most importantly, the code > depends > almost everywhere on the hardware flags [z]ero, [s]ign and [x,b,c]arry. > > Now, when I thought about porting Pil64 to RISC-V, it came as a shock to > me that > RISC-V has no CPU flags at all!! It is the first time that I encountered a > CPU > without flags. It means, Pil64 cannot be efficiently ported to RISC-V :( > > So I had to think completely new. LLVM is everywhere now, and other people > take > care of all this architecture mess. > > PilVM (the PicoLisp-like language Pil21 is written in) directly maps to > LLVM-IR, > which is *not* a machine with a fixed well-defined set of registers. It is > an > SSA (static single assignment) architecture, meaning you have an infinite > number > of registers, where each is assigned a value exactly once, and never > modified. > > LLVM-IR is a little more low-level than C (it allows, for example, to > manipulate > the stack to a certain level, and supports overflow in arithmetic > operations). > But there is no easy way to map Pil64 to it. > > Pil64 is a *lot* more low level (and thus extremly fast), so the > interesting > part will be whether the many optimizing features of LLVM will give a > machine of > similar performance. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
