On Mon, May 12, 2014 at 8:06 AM, Alexander Burger <a...@software-lab.de> wrote: > Hi Will, > thanks for you long explanation!
Right, and thanks to all for this interesting journey in the internals. > The problem with this is that is horribly inefficient. I'm interested by a clang compatible version, just to see what emscripten will make of it. For the sake of the experience I'm gonna try anyway. The problem is it could take me some time. If someone fluent in C could try, that would be interesting!!! (sorry, I haven't much more to offer). By the way, is the source of miniPicoLisp in the repo at code.google? https://code.google.com/p/picolisp/source/browse/ chri -- http://profgra.org/lycee/ (site pro) http://delicious.com/profgraorg (liens, favoris) https://twitter.com/profgraorg On Mon, May 12, 2014 at 10:59 AM, <andr...@itship.ch> wrote: >> And this is an excellent example of PicoLisp going the extra mile. Instead >> of handling C as the lowest abstraction, going to the actual machine. I >> imagine other interpreted languages could be faster if designed with this >> attention to detail. >> > > Exactly! > > Thank you Alex, for the insightful explanation. > >> On 12 maj 2014 08:24:13 CEST, Alexander Burger <a...@software-lab.de> >> wrote: >>>On Mon, May 12, 2014 at 08:06:57AM +0200, Alexander Burger wrote: >>>> The problem with this is that is horribly inefficient. The dynamic >>>version >>>> >>>> myStruct bnd[length(x)]; >>>> >>>> simply decrements the stack pointer by "length(x) * sizeof(myStruct)" >>>> (which is a single machine instruction!), while the malloc() call >>>> involves the whole memory management machinery. >>> >>>BTW, this inability of C to properly support stack manipulations was >>>the >>>main reason to write the 64-bit version of PicoLisp in assembly. >>> >>> >>>As I wrote this in http://software-lab.de/doc64/README >>> >>>The reasons to choose assembly language (instead of C) were, in >>>decreasing order >>> of importance: >>> >>> 1. Stack manipulations >>>Alignment to cell boundaries: To be able to directly express the >>>desired >>> stack data structures (see "doc64/structures", e.g. "Apply frame"), a >>> better control over the stack (as compared to C) was required. >>> >>>Indefinite pushs and pops: A Lisp interpreter operates on list >>>structures >>>of unknown length all the time. The C version always required two >>>passes, >>>the first to determine the length of the list to allocate the necessary >>>stack structures, and then the second to do the actual work. An >>>assembly >>>version can simply push as many items as are encountered, and clean up >>>the >>> stack with pop's and stack pointer arithmetics. >>> >>> ... >>> >>> >>> >>>Pushing and popping data of unknown length is at the heart of the >>>PicoLisp >>>interpreter. It is done all the time. >>> >>> >>>Note that even with arrays of variable length, as in the discussed >>>case: >>> >>> myStruct bnd[length(x)]; >>> >>>it is still not optimal, because the interpreter has to call length() >>>on >>>the list first, before actually processing it. The list needs to be >>>traversed twice. >>> >>>In a language with proper stack control, you can simply call 'push' in >>>the loop doing the processing. >>> >>>♪♫ Alex >>>-- >>>UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >> >> -- >> Skickat från min Android-telefon med K-9 E-post. Ursäkta min >> fåordighet. >> > > > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- http://profgra.org/lycee/ (site pro) http://delicious.com/profgraorg (liens, favoris) https://twitter.com/profgraorg -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
