[Openmcl-devel] tagbody and go

[Taoufik Dachraoui]

Hi

Sorry but I found that what I wrote about macros is non-sense in most times

i have to be more careful and it is better that I ponder twice before i
write something

sorry again, I have to go back to my books and be more careful on details
this time

PS: i decided to use a vector of functions in my simulator

Kind regards
Taoufik

On Wed, Dec 8, 2010 at 11:02 PM, Taoufik Dachraoui <
dachraoui.taoufik at gmail.com> wrote:

> I think that I will use a vector with body of code, and a macro, as my
> tests show it is 3 times faster
> than having a compiled lambdas that I funcall.
>
> It is something like the following:
> (defvar *opcode* 0)
> (defvar *codes* (make-array 100 :element-type 'cons))
> (defmacro run-inst ()  `,(svref *codes* *opcode*))
> (setf (svref *codes* 10) '(setf r3 (+ r1 r2))) ; add
> (setf (svref *codes* 20) '(setf r3 (* r1 r2))) ; mul
> (setf *opcode* 10) ; addition
> (run-inst)
> (setf *opcode* 20) ; multiplication
> (run-inst)
> ....
>
> The tests in my previous posting show that using a vector and a macro
> is 3 times faster than using compiled lambdas
>
> Kind regards
> Taoufik
>
>
>
> On Wed, Dec 8, 2010 at 10:33 PM, Robert Goldman <rpgoldman at sift.info>wrote:
>
>> On 12/8/10 Dec 8 -3:20 PM, Taoufik Dachraoui wrote:
>> > I am writing a compiler for a pure functional language with completely
>> > lazy evaluation (sharing).
>> >
>> > The compiler generates binary code for a virtual machine. I am trying to
>> > implement a simulator for it.
>> >
>> > It is easy to implement the simulator using cond (or ecase), but I
>> > thought if it does not cost me
>> > time why not implement it more efficiently. So, for performance issues I
>> > would like the simulator,
>> > for each encountered instruction (the opcode is represented by 1 byte),
>> > to directly jump to the
>> > corresponding code.
>>
>> Apologies if I'm being foolish, but why can't you just make a vector
>> that's full of thunks (compiled lambdas of no arguments)?
>>
>> Best,
>> r
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20101209/30a8d31d/attachment.htm>