patching gcc to allow other calling conventions

patching gcc to allow other calling conventions

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 2449 bytes --]

Hi,

After poking around with inline assembler I conclude that it's possible to
use inline assembler and macrology
to implement some kind of other calling convention that s suitable for
guile. at -O0.

But we want -O3, and then we are sold with this approach.

Another option is perhaps to follow the clues in wingo:s link e.g.

   http://atgreen.github.com/ggx/

And make specific arch with our calling mechansim or perhaps even better
extend gcc to allow us to mix
c-call convention and guile specific.

Anyway currently most of the porting of SBCL assembler for x86-64 is done
and with this tool I'm experimenting
with a simple JIT engine.

You can follow the progress at https://gitorious.org/aschm/aschm

Currently I can build code to a byte vector and execute it and now most of
the assembler works.

My plan is to keep the current byte-code as a on file media and then allow
to compile the code to a simple native format
(Say a 10-20x increase in size). I plan add a new type of  objectcode
datastructure where we will run the code in native mode
If a new function is evaluated that is not compiled to native it will
compile it and use that so that the usual lazyness will be employed.
The complications of this method will be very low. It will basically branch
off to support code for expensive instructions and try to emit at most say
10 native instructions for every byte opcode. In all not much more then a
glorified virtual engine. However I would expect some loops with simple
instructions to be as fast as what wingo just posted on the list e.g. A
simple loop will do 250-500M turns in a second.

My personal view is that improvement of our code base has to be
incrementally and that experiments of reasonable size and scope should be
done, then we can learn and at some point carve out a step forward.

I think this is a doable experiment. I have a question here. I would need
to add some code to guile in order to hook in this machine and it would
be nice to try that out in a guile branch. Shall I do all this in a local
repo or do you want to join. I fell like adding another guile repo in
github or gitorious is pushing things a litle and maybe we could start a
guile-wipedy-jit branch.

The reason I wanted to fork sbcl is that it has assemblers for
x86,x86-64,alpha,hppa,sparc,ppc,mips e.g a few targets. It would be nice to
know what targets to focus on or if we need to add anyone else to the list!

Anyway have fun!

/Stefan

[-- Attachment #2: Type: text/html, Size: 2692 bytes --]

Re: patching gcc to allow other calling conventions

[Ludovic Courtès]

Hi Stefan,

Stefan Israelsson Tampe <stefan.itampe@gmail.com> skribis:

> The reason I wanted to fork sbcl is that it has assemblers for
> x86,x86-64,alpha,hppa,sparc,ppc,mips e.g a few targets. It would be nice to
> know what targets to focus on or if we need to add anyone else to the list!

Did you consider starting from GNU/MIT Scheme?  It supports only IA32
and x86_64, I think, but it’s in Scheme, and it’s GNU.

Thanks,
Ludo’.

Re: patching gcc to allow other calling conventions

[Noah Lavine]

Hello,

> Did you consider starting from GNU/MIT Scheme?  It supports only IA32
> and x86_64, I think, but it’s in Scheme, and it’s GNU.

Actually, that's an interesting thought in general. I looked at MIT
scheme a bit a long time ago, but I believe it uses two intermediate
languages, a high-level one similar to Tree-IL and a low-level one
that I don't know much about. We might be able to turn Tree-IL into
the high-level one and use their compiler infrastructure. Since
they're a GNU project, there might not be copyright issues.

However, I'm not sure if this has advantages over just building it
ourselves. And I don't know if the MIT Scheme developers would like
this or not.

Noah

Re: patching gcc to allow other calling conventions

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]

I can code an independent assembler later I do now most of the complexites
now and a lot of the code can be removed.

But the used sbcl derivative although not gnu is either in the public
domain or bsd so we should be able to publish what we are doing. I prefere
now to start working on a simple jit scheme for the fun of it, because it
is a good learning experience and that getting results are a good driver to
continueu.

/stefan
Den 18 jun 2012 02:43 skrev "Noah Lavine" <noah.b.lavine@gmail.com>:

> Hello,
>
> > Did you consider starting from GNU/MIT Scheme?  It supports only IA32
> > and x86_64, I think, but it’s in Scheme, and it’s GNU.
>
> Actually, that's an interesting thought in general. I looked at MIT
> scheme a bit a long time ago, but I believe it uses two intermediate
> languages, a high-level one similar to Tree-IL and a low-level one
> that I don't know much about. We might be able to turn Tree-IL into
> the high-level one and use their compiler infrastructure. Since
> they're a GNU project, there might not be copyright issues.
>
> However, I'm not sure if this has advantages over just building it
> ourselves. And I don't know if the MIT Scheme developers would like
> this or not.
>
> Noah
>
>

[-- Attachment #2: Type: text/html, Size: 1565 bytes --]

Re: patching gcc to allow other calling conventions

[Noah Lavine]

Hello,

> But the used sbcl derivative although not gnu is either in the public domain
> or bsd so we should be able to publish what we are doing. I prefere now to
> start working on a simple jit scheme for the fun of it, because it is a good
> learning experience and that getting results are a good driver to continueu.

A JIT would be a good thing for Guile to have. I worked on a JIT a
while ago, and I found that the hard part was not generating machine
code or connecting it to the VM - both of which it looks like you've
done - but making the JIT engine understand all of the VM
instructions. You could just hard-code them all, but then you've got a
complete duplicate of vm-engine.c with exactly the same information,
but in different syntax. So I thought I wanted some way to generate
the JIT from vm-engine.c, but that requires parsing C code. That's a
capability I want Guile to have in general, but I haven't made it
happen yet.

What do you think about this? Would you just want to maintain the JIT
engine separately from vm-engine.c, or would you like to automatically
generate it?

(Note: you could also generate vm-engine.c and your JIT from some
third source, but I think we rejected that for being too complicated.
It would certainly make the build process more difficult.)

Noah

> /stefan
>
> Den 18 jun 2012 02:43 skrev "Noah Lavine" <noah.b.lavine@gmail.com>:
>
>> Hello,
>>
>> > Did you consider starting from GNU/MIT Scheme?  It supports only IA32
>> > and x86_64, I think, but it’s in Scheme, and it’s GNU.
>>
>> Actually, that's an interesting thought in general. I looked at MIT
>> scheme a bit a long time ago, but I believe it uses two intermediate
>> languages, a high-level one similar to Tree-IL and a low-level one
>> that I don't know much about. We might be able to turn Tree-IL into
>> the high-level one and use their compiler infrastructure. Since
>> they're a GNU project, there might not be copyright issues.
>>
>> However, I'm not sure if this has advantages over just building it
>> ourselves. And I don't know if the MIT Scheme developers would like
>> this or not.
>>
>> Noah
>>
>

Re: patching gcc to allow other calling conventions

[Ludovic Courtès]

Hi,

Noah Lavine <noah.b.lavine@gmail.com> skribis:

> (Note: you could also generate vm-engine.c and your JIT from some
> third source, but I think we rejected that for being too complicated.
> It would certainly make the build process more difficult.)

Right, but I would still consider it better & easier than parsing all
the bodies of the ‘VM_DEFINE_INSTRUCTION’…

Thanks,
Ludo’.

Re: patching gcc to allow other calling conventions

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 2462 bytes --]

Why not specify the logic in scheme and output it either to C or Assembler
:-)

/Stefan

On Tue, Jun 19, 2012 at 12:30 AM, Noah Lavine <noah.b.lavine@gmail.com>wrote:

> Hello,
>
> > But the used sbcl derivative although not gnu is either in the public
> domain
> > or bsd so we should be able to publish what we are doing. I prefere now
> to
> > start working on a simple jit scheme for the fun of it, because it is a
> good
> > learning experience and that getting results are a good driver to
> continueu.
>
> A JIT would be a good thing for Guile to have. I worked on a JIT a
> while ago, and I found that the hard part was not generating machine
> code or connecting it to the VM - both of which it looks like you've
> done - but making the JIT engine understand all of the VM
> instructions. You could just hard-code them all, but then you've got a
> complete duplicate of vm-engine.c with exactly the same information,
> but in different syntax. So I thought I wanted some way to generate
> the JIT from vm-engine.c, but that requires parsing C code. That's a
> capability I want Guile to have in general, but I haven't made it
> happen yet.
>
> What do you think about this? Would you just want to maintain the JIT
> engine separately from vm-engine.c, or would you like to automatically
> generate it?
>
> (Note: you could also generate vm-engine.c and your JIT from some
> third source, but I think we rejected that for being too complicated.
> It would certainly make the build process more difficult.)
>
> Noah
>
> > /stefan
> >
> > Den 18 jun 2012 02:43 skrev "Noah Lavine" <noah.b.lavine@gmail.com>:
> >
> >> Hello,
> >>
> >> > Did you consider starting from GNU/MIT Scheme?  It supports only IA32
> >> > and x86_64, I think, but it’s in Scheme, and it’s GNU.
> >>
> >> Actually, that's an interesting thought in general. I looked at MIT
> >> scheme a bit a long time ago, but I believe it uses two intermediate
> >> languages, a high-level one similar to Tree-IL and a low-level one
> >> that I don't know much about. We might be able to turn Tree-IL into
> >> the high-level one and use their compiler infrastructure. Since
> >> they're a GNU project, there might not be copyright issues.
> >>
> >> However, I'm not sure if this has advantages over just building it
> >> ourselves. And I don't know if the MIT Scheme developers would like
> >> this or not.
> >>
> >> Noah
> >>
> >
>

[-- Attachment #2: Type: text/html, Size: 3172 bytes --]

Re: patching gcc to allow other calling conventions

[Daniel Krueger]

Hey,

On Thu, Jun 21, 2012 at 2:32 PM, Stefan Israelsson Tampe
<stefan.itampe@gmail.com> wrote:
> Why not specify the logic in scheme and output it either to C or Assembler
> :-)

That sounds very cool, and would be very cool, I thought first, but
then I realized that you wouldn't be able to bootstrap guile anymore
:-/

- Daniel

Re: patching gcc to allow other calling conventions

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

Yes this can be an issue.

On a second thought guile do have an initital interpreter that is either a
vm or a native no?
Perhaps one can make use of that somehow!

/Stefan

On Thu, Jun 21, 2012 at 7:14 PM, Daniel Krueger <keenbug@googlemail.com>wrote:

> Hey,
>
> On Thu, Jun 21, 2012 at 2:32 PM, Stefan Israelsson Tampe
> <stefan.itampe@gmail.com> wrote:
> > Why not specify the logic in scheme and output it either to C or
> Assembler
> > :-)
>
> That sounds very cool, and would be very cool, I thought first, but
> then I realized that you wouldn't be able to bootstrap guile anymore
> :-/
>
> - Daniel
>

[-- Attachment #2: Type: text/html, Size: 1051 bytes --]

Re: patching gcc to allow other calling conventions

[Daniel Krueger]

On Thu, Jun 21, 2012 at 7:50 PM, Stefan Israelsson Tampe
<stefan.itampe@gmail.com> wrote:
> On a second thought guile do have an initital interpreter that is either a
> vm or a native no?
> Perhaps one can make use of that somehow!

Yeah, I thought about that too, but thought first that it would be
impossible. But if you first only compile the interpreter code
(without the VM), then create the C file with the instructions and
compile the VM it should work. I think .. ^^

- Daniel

Re: patching gcc to allow other calling conventions

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

Hmm, yes then it can work.

I would compile only to C at the first phase as you say as it should not be
of too high
complexity to output the C part and be pretty swift although you are
interpreting. Then the VM can compile all guile including code to emit and
compile assembler and then one can add the possibility to compile to native
code by some kind of just in time mechanism. Cool!

I will try to start investigating this approach.

/Stefan

On Thu, Jun 21, 2012 at 7:57 PM, Daniel Krueger <keenbug@googlemail.com>wrote:

> On Thu, Jun 21, 2012 at 7:50 PM, Stefan Israelsson Tampe
> <stefan.itampe@gmail.com> wrote:
> > On a second thought guile do have an initital interpreter that is either
> a
> > vm or a native no?
> > Perhaps one can make use of that somehow!
>
> Yeah, I thought about that too, but thought first that it would be
> impossible. But if you first only compile the interpreter code
> (without the VM), then create the C file with the instructions and
> compile the VM it should work. I think .. ^^
>
> - Daniel
>

[-- Attachment #2: Type: text/html, Size: 1487 bytes --]

Re: patching gcc to allow other calling conventions

[Ludovic Courtès]

Hi,

Daniel Krueger <keenbug@googlemail.com> skribis:

> On Thu, Jun 21, 2012 at 2:32 PM, Stefan Israelsson Tampe
> <stefan.itampe@gmail.com> wrote:
>> Why not specify the logic in scheme and output it either to C or Assembler
>> :-)
>
> That sounds very cool, and would be very cool, I thought first, but
> then I realized that you wouldn't be able to bootstrap guile anymore
> :-/

The generated C file would be shipped in the distribution, just like
psyntax-pp.scm.

Thanks,
Ludo’.