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
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
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,
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
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 PPC
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]
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
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
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]
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)
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
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))
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.
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, but
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,
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,
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 rewrite.
18 matches
Mail list logo
