Re: Status of 64 picoLisp

Hi Tomas, > > This helped a lot! The 634 seconds reduced to 37 seconds, a 17-fold > > speed improvement :-) > > great! Does it mean that the speed is proportional to the number of > digits processed in one go, i.e. about 9 times faster on a 32 system and > about 18 times faster on a 64 bit syste

Re: Status of 64 picoLisp

HI Alex, > larger "digits". So I rewrote it, so that a single BCD digit is no > longer a byte, but a complete word, holding 9 BCD digits on 32 bits, and > 18 digits on 64 bits. > > This helped a lot! The 634 seconds reduced to 37 seconds, a 17-fold > speed improvement :-) great! Does it mean tha

Re: Status of 64 picoLisp

Hi Tomas, last year we had this discussion: On Thu, Apr 02, 2009 at 09:20:57AM +0100, Tomas Hlavaty wrote: > Hi Alex, > > > However, I am aware of the fact that in picoLisp the printing of > > numeric results is often much more expensive than the actual > > calculations, due to the conversions n

Re: Status of 64 picoLisp

Hi Randall, > For some people, a 11,185,272 digit number is very interesting ;-) You are very right. However, for such a specialized calculation even I would not use picoLisp. :-) Cheers, - Alex -- UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Re: Status of 64 picoLisp

Hi Alex, I should have sent this yesterday on April 1 - but it is true! For some people, a 11,185,272 digit number is very interesting ;-) http://www.mersenne.org/ Maybe they should use picolisp. Cheers, - Rand On Thu, Apr 2, 2009 at 1:09 PM, Alexander Burger wrote: > Hi Tomas, > >> Int

Re: Status of 64 picoLisp

Hi Tomas, > Interesting, it does not seem to make much difference with the C > version when I take the final 'printf' out of the C code. That's why I suspect that there might be a way to speed it up. On the other hand, bignum packages in C usually work with fixed length arrays (as opposed to lin

Re: Status of 64 picoLisp

Hi Alex, > However, I am aware of the fact that in picoLisp the printing of > numeric results is often much more expensive than the actual > calculations, due to the conversions necessary for the decimal base. > If I take out the final (prinl Y) from gmp-test2.l, I get: > It makes a considerable

Re: Status of 64 picoLisp

Hi Tomas, it may be a bit late by now, but I'd like to write some comments about your posting last year, concerning bignum performance. On Thu, Oct 16, 2008 at 11:57:07AM +0100, Tomas Hlavaty wrote: > I was curious to try picolisp bignums and must say that for somebody > doing anything serious,

Re: Status of 64 picoLisp

Hi Eugene, > Apologies for the earlier HTMLized colour, etc in posting. This time > should be plain text. Ah, great! That's much easier to read :-) > In case you are having issues with GAS, you may want to look at YASM I think that the GNU assembler is all right, as it supports a lot of a

Re: Status of 64 picoLisp

Apologies for the earlier HTMLized colour, etc in posting. This time should be plain text. Hi Alex, Thank you for the clarifications. In case you are having issues with GAS, you may want to look at YASM from what I can see it's under active deve

Re: Status of 64 picoLisp

Hi Alex, Thank you for the clarifications. In case you are having issues with GAS, you may want to look at YASM=C2=A0 from wha= t I can see it's under active development and the source looks reasonably clean. Cheers, Eugene Alexander Burger wrote: Hi Eugene, thanks for your comments!

Re: Status of 64 picoLisp

On Tue, Oct 21, 2008 at 09:20:30AM +1100, konrad Zielinski wrote: > THe interesting thing will be handling C structs. As almost every > interesting C API makes heavy use of them. Well, you know, I don't want to discuss such things prematurely. But as you insist ... ;-) Consulting my last year's

Re: Status of 64 picoLisp

THe interesting thing will be handling C structs. As almost every interesting C API makes heavy use of them. My wish list would be to be able to create them from inside pico and use them just like a native object. IE pass them arround as the values of symbols and use 'get' and 'put' to read and wr

Re: Status of 64 picoLisp

Hi Eugene, thanks for your comments! :-) > It would appear that you could claim portability to any CPU. Afterall, > porting should only require writing a translator module for the Well, not really any CPU. It should have a 64 bit word size, with 8 bits per byte. And if it is a CPU that requires

Re: Status of 64 picoLisp

Alex ! THANK YOU for sharing your design and rationale for the "picoLisp64". After reading your example and explanations, I fully understand and agree with your decision to use assembler and to not use LLVM. By sharing your roadmap for the future, you have increased the confidence level in t

Re: Status of 64 picoLisp

Hi Tomas, > > Yes, the current version of "gcc.l" will not work any longer :-( > > What is the reason for this not being possible? I though C and asm > can be linked together (C is compiled to asm anyway). On the instruction level this is correct, but the calling conventions of the (assembly) f

Re: Status of 64 picoLisp

Hi Alex, > Yes, the current version of "gcc.l" will not work any longer :-( What is the reason for this not being possible? I though C and asm can be linked together (C is compiled to asm anyway). Cheers, Tomas -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]

Re: Status of 64 picoLisp

On Thu, Oct 16, 2008 at 10:24:40PM +1100, konrad Zielinski wrote: > And now back to questions about 64 bit picolisp: > > Is switching to an assembler going to mean the demise of gcc.l ? > Are we going to see inline picoLisp Assembler instead?O Yes, the current version of "gcc.l" will not work any

Re: Status of 64 picoLisp

Hi Tomas, > I was curious to try picolisp bignums and must say that for somebody > doing anything serious, it is probably rather inefficient. As a I'm aware of that. The bignum implementation was not intended to be particularly fast, or - to put it corrrectly - cannot be expected to be very fast

Re: Status of 64 picoLisp

Hi All, It would appear that setting up a chroot is remarkably easy, well under debian anyway, I can't speak for other distros as I haven't tried. AndJus it seems to work quite nicely too, even if their are other ways to do it. Anyway now that I have a chroot I can install a version of Firefox wi

Re: Status of 64 picoLisp

Hi Alex, thanks for explanation. I was curious to try picolisp bignums and must say that for somebody doing anything serious, it is probably rather inefficient. As a benchmark, I tried the example from http://paste.lisp.org/display/15116 (setq X 0) (setq Y 1) (for (N 2 (<= N 100) (inc N))

Re: Status of 64 picoLisp

> Hi Jakob, > > while LLVM is surely an interesting project, I think it would by far be > overkill for what we need here. Indeed. What you are doing is very interesting by the way. // Jako -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]

Re: Status of 64 picoLisp

Hi Tomas, > I guess that miniPicoLisp is not 64 bit incarnation of future > picoLisp-3 then? Right, it is rather limited, and more of a design study than. > What are the reasons for a) complete rewrite and b) switching from C > to asm? As Konrad noted, there is - due to the doubled word size -

Re: Status of 64 picoLisp

On Wed, Oct 15, 2008 at 10:27:59PM +0100, Tomas Hlavaty wrote: > your 64 bit Linux fine. You'll need to add the -m32 option to gcc.l .. or download the latest "testing" version. -- UNSUBSCRIBE: mailto:[EMAIL PROTECTED]

Re: Status of 64 picoLisp

Hi Jakob, while LLVM is surely an interesting project, I think it would by far be overkill for what we need here. What I'm doing is extremely simple. I defined a (mostly) single-address assembly language, with a rather basic set of instructions which I believe can easily be mapped to differing ar

Re: Status of 64 picoLisp

> 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 use

Re: Status of 64 picoLisp

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

Re: Status of 64 picoLisp

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

Re: Status of 64 picoLisp

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

Re: Status of 64 picoLisp

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

Re: Status of 64 picoLisp

> 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

Re: Status of 64 picoLisp

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,

Re: Status of 64 picoLisp

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