FFI problem: too many arguments

Marcus Denker denker at iam.unibe.ch
Mon Feb 20 08:58:56 UTC 2006


On 19.02.2006, at 16:11, nicolas cellier wrote:


>
> Then it seems that i would better rely on this one. I will upload.
> But i saw that some work is on progress on 3.9 image, and that  
> seems to be on
> the "old" compiler...
>

We should not stop fixing the old Compiler just because there might  
be something
else in the future.

The new Compiler's last version requires 3.9a (not the newest, I need  
to fix a bunch
of things for that). I should make it simpler to obtain an image.

I'l make a page describing the process and make a ready to use image.  
The best
thing right now for playing is to dowload the ByteSurgeon image:

   http://www.iam.unibe.ch/~scg/Research/ByteSurgeon/

But this will change: The new Compiler will be a simple package to  
load in 3.9a
very soon.

> What are the Squeak plans ?

Good Question.... I'm slowly working on getting the compiler into  
shape for
beeing in theory a replacement. But I have to admit that efforts  
stalled a
bit after I got it far enough for the experiments I wanted to do...

(Which included to make the compiler not closure-only, now it's  
configurable
by a preference to either generate old-style blocks or BlockClosures).

> Include anthony's in the future base image ?

I would like to see it replacing the old one eventually, but for that  
some
work needs to be done that I didn't yet do... e.g. we need
better error-reporting for SmaCC based parsers, and boostrapping  
(recreating
parser with SmaCC) need old compiler right now.
And of course bugs need to be weeded out.

> Does it need more testing first ?

Definitly.

> Are there any pros and cons i should be aware of ?

Pro:
  - much easier to understand and change.
  - provides a lot of very interesting infrastructure
    vital for what Squeak is all about (inventing the future):
     -- better AST Design (parent pointer, visitor)
        (perfect for eToy like stuff, syntax experiments, pretty  
printers, analyzers)
     -- Backend (IRBuilder) can be used independendly (kind of a  
"Squeak Macro Assember")
         (it's even retargable towards the actual bytecode set used,  
cool for experimenting
          with hacked VMs, makes VM evolution easier).
     -- SmaCC based Parser. Easy to adapt and change.
     -- easy manipulation of bytecode with ByteSurgeon
- optional Block Closure support.

Con:
  - Compiling is slower (factor 3)
  - Consists of much more Classes ;-)
  - error reporting worse then the old one.
  - Bugs (e.g. decompiling not yet 100% working)


    Marcus





More information about the Squeak-dev mailing list