Hi Alex,
I was just wondering what the current status of 64 bit picolisp is.
I;m on a 64 bit system which for the moment has prevented me from
trying out Thomas's Async read and write code.
I'm working on a 32 bit chroot enviornment to run pico in for now, but
it would be nice to go native.
Does
Hi Konrad,
> I was just wondering what the current status of 64 bit picolisp is.
The good news: It is under work since more than one year now :-)
The bad new: I'm afraid it will still take quite a while :-(
I do not want to go public with it before I'm sure that most details are
settled down. B
On 15 Oct 2008, at 9:11 AM, Alexander Burger wrote:
> It is a complete rewrite. Even the implementation language changed.
> Instead of C it is written in a generic assembler (which in turn is
> written in PicoLisp :) that generates GNU assembler code (currently
> there is only a x86-64 generator,
> On 15 Oct 2008, at 9:11 AM, Alexander Burger wrote:
>
>> It is a complete rewrite. Even the implementation language changed.
>> Instead of C it is written in a generic assembler (which in turn is
>> written in PicoLisp :) that generates GNU assembler code (currently
>> there is only a x86-64 gene
Hi Konrad,
> I;m on a 64 bit system which for the moment has prevented me from
> trying out Thomas's Async read and write code. I'm working on a 32
> bit chroot enviornment to run pico in for now, but it would be nice
> to go native.
It should work even on 64 bit Linux without chroot environment
Hi Alex,
thank you for explanation.
Cheers,
Tomas
--
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
Hi Alex,
> It is a complete rewrite. Even the implementation language changed.
> Instead of C it is written in a generic assembler (which in turn is
> written in PicoLisp :) that generates GNU assembler code (currently
> there is only a x86-64 generator, but other CPUs are possible).
I guess that
I suspect this would be in contradiction to some of the stated goals
of PicoLisp,
For one you would no longer be close to the machine. Just close to the
virtual machine.
On 16/10/2008, Jakob <[EMAIL PROTECTED]> wrote:
>> On 15 Oct 2008, at 9:11 AM, Alexander Burger wrote:
>>
>>> It is a complete
No matter how efficient or clever a virtual machine, it still requires
additional steps in order to perform useful work. So there are really
three "efficient" approaches to consider:
1. Accept that we have a ubiquitous x86(-64) mono-culture and
primarily target that.
(I'm assuming that
