GNAT with LLVM -> Java Script

GNAT with LLVM -> Java Script

[David Botton]

So wondering why I would want an LLVM backend for GNAT, LLVM has support to output ASM.JS, i.e. Java Script

http://www.humblebundle.com/

The current games in the bundle are traditional desktop video games now running as plan Java Script, no plugins, in a browser.

Gnoga would be a perfect fit for a Gnat that output to JS, instant control of the browser running all client side.

David Botton

Re: GNAT with LLVM -> Java Script

[Luke A. Guest]

David Botton <david@botton.com> wrote:
> So wondering why I would want an LLVM backend for GNAT, LLVM has support
> to output ASM.JS, i.e. Java Script
> 
> http://www.humblebundle.com/
> 
> The current games in the bundle are traditional desktop video games now
> running as plan Java Script, no plugins, in a browser.
> 
> Gnoga would be a perfect fit for a Gnat that output to JS, instant
> control of the browser running all client side.
> 
> David Botton

I extracted the llvm code from another project, it's GPL. It's from a vhdl
compiler iirc.

I can put it up somewhere if you like.

Re: GNAT with LLVM -> Java Script

[David Botton]

> I can put it up somewhere if you like.

At some point would be good, I don't have the time yet to look in to it and probably not the best person for the job. However if no one does eventually I'll try my hand at it.

Re: GNAT with LLVM -> Java Script

[Brian Drummond]

On Wed, 15 Oct 2014 01:47:04 +0000, Luke A. Guest wrote:

> David Botton <david@botton.com> wrote:
>> So wondering why I would want an LLVM backend for GNAT, LLVM has
>> support to output ASM.JS, i.e. Java Script
>> 
>> http://www.humblebundle.com/
>> 
>> The current games in the bundle are traditional desktop video games now
>> running as plan Java Script, no plugins, in a browser.
>> 
>> Gnoga would be a perfect fit for a Gnat that output to JS, instant
>> control of the browser running all client side.
>> 
>> David Botton
> 
> I extracted the llvm code from another project, it's GPL. It's from a
> vhdl compiler iirc.
> 
> I can put it up somewhere if you like.

Would that be from ghdl? If so,
http://sourceforge.net/projects/ghdl-updates/?source=navbar
and check out the trunk. There is quite a bit of active development on 
it, but not much on the LLVM back end at the moment.

- Brian

Re: GNAT with LLVM -> Java Script

[Lucretia]

On Wednesday, 15 October 2014 10:15:51 UTC+1, Brian Drummond  wrote:
> 
> >> David Botton
> > 
> > I extracted the llvm code from another project, it's GPL. It's from a
> > vhdl compiler iirc.
> > 
> > I can put it up somewhere if you like.
> 
> Would that be from ghdl? If so,
> http://sourceforge.net/projects/ghdl-updates/?source=navbar
> and check out the trunk. There is quite a bit of active development on 
> it, but not much on the LLVM back end at the moment.

Yup.

There are also the bindings that were written and then abandoned by Duncan Sands, don't know if they are more advanced or not.

Luke.

Re: GNAT with LLVM -> Java Script

[Brian Drummond]

On Wed, 15 Oct 2014 02:59:20 -0700, Lucretia wrote:

> On Wednesday, 15 October 2014 10:15:51 UTC+1, Brian Drummond  wrote:
>> 
>> >> David Botton
>> > 
>> > I extracted the llvm code from another project, it's GPL. It's from a
>> > vhdl compiler iirc.
>> > 
>> > I can put it up somewhere if you like.
>> 
>> Would that be from ghdl? If so,
>> http://sourceforge.net/projects/ghdl-updates/?source=navbar and check
>> out the trunk. There is quite a bit of active development on it, but
>> not much on the LLVM back end at the moment.
> 
> Yup.
> 
> There are also the bindings that were written and then abandoned by
> Duncan Sands, don't know if they are more advanced or not.
> 
> Luke.

That was the DragonEgg project, wasn't it? I got the impression it 
foundered on some shortcoming of LLVM for non-C languages; not certain 
which, but possibly the one regarding nested functions that Tristan has 
overcome with ghdl.

- Brian

Re: GNAT with LLVM -> Java Script

[Luke A. Guest]

Brian Drummond <brian3@shapes.demon.co.uk> wrote:
.
>> 
>> Yup.
>> 
>> There are also the bindings that were written and then abandoned by
>> Duncan Sands, don't know if they are more advanced or not.
>> 
>> Luke.
> 
> That was the DragonEgg project, wasn't it? I got the impression it 
> foundered on some shortcoming of LLVM for non-C languages; not certain 
> which, but possibly the one regarding nested functions that Tristan has 
> overcome with ghdl.

No, DragonEgg was the plugin that followed, think that's dead also.

But you're right, the nested function thing was a problem but I'm certain
Duncan said he was working will llvm way back to sort it out. Don't know
how far it got.

Luke

Re: GNAT with LLVM -> Java Script

[Georg Bauhaus]

On 16.10.14 17:10, Luke A. Guest wrote:
> Brian Drummond <brian3@shapes.demon.co.uk> wrote:

>> That was the DragonEgg project, wasn't it? I got the impression it
>> foundered on some shortcoming of LLVM for non-C languages; not certain
>> which, but possibly the one regarding nested functions that Tristan has
>> overcome with ghdl.
>
> No, DragonEgg was the plugin that followed, think that's dead also.
>
> But you're right, the nested function thing was a problem but I'm certain
> Duncan said he was working will llvm way back to sort it out. Don't know
> how far it got.

Apple's Swift language is using LLVM, and it has nested functions.
In fact, closures. Maybe this support can be stripped down to Ada's needs?

Re: GNAT with LLVM -> Java Script

[duncan.sands]

Hi,

> > That was the DragonEgg project, wasn't it? I got the impression it 
> 
> > foundered on some shortcoming of LLVM for non-C languages; not certain 
> 
> > which, but possibly the one regarding nested functions that Tristan has 
> 
> > overcome with ghdl.

no, there were no blocking technical problems.  For example I got nested function support working properly a gazillion years ago, as Luke says.  Exception handling took longer to be completely reliable, but that was also resolved years ago too.  In both cases changes needed to be made to LLVM, but those changes are all old hat now.  All that happened is that I lost interest in the project and no-one stepped forward to take it over.  That means that it's been quietly bit rotting for a while now.  For example: to accommodate internal changes in gcc-4.7 and later, dragonegg's ABI support needs to be rewritten, but I'd already lost interest in the project so never did it, which means that while it still mostly sorta works, thanks to some hacks, the plugin easily crashes on Ada tagged types starting from this gcc version.

Ciao, Duncan.

> 
> 
> 
> No, DragonEgg was the plugin that followed, think that's dead also.
> 
> 
> 
> But you're right, the nested function thing was a problem but I'm certain
> 
> Duncan said he was working will llvm way back to sort it out. Don't know
> 
> how far it got.
> 
> 
> 
> Luke

Re: GNAT with LLVM -> Java Script

[Brian Drummond]

On Fri, 17 Oct 2014 00:38:35 -0700, duncan.sands wrote:

> Hi,
> 
>> > That was the DragonEgg project, wasn't it? I got the impression it
>> 
>> > foundered on some shortcoming of LLVM for non-C languages; 

> no, there were no blocking technical problems.  For example I got nested
> function support working properly a gazillion years ago, as Luke says. 
> Exception handling took longer to be completely reliable, but that was
> also resolved years ago too.  In both cases changes needed to be made to
> LLVM, but those changes are all old hat now.  All that happened is that
> I lost interest in the project and no-one stepped forward to take it
> over.  That means that it's been quietly bit rotting for a while now. 

Thank you for the correction.

Is it still accessible somewhere? If someone were to pick it up, where 
would you suggest they start? (which repo, and any major tasks and hints 
that immediately come to mind?)

> For example: to accommodate internal changes in gcc-4.7 and later,
> dragonegg's ABI support needs to be rewritten, but I'd already lost
> interest in the project so never did it, which means that while it still
> mostly sorta works, thanks to some hacks, the plugin easily crashes on
> Ada tagged types starting from this gcc version.

Yeah, changes around gcc-4.7 caused considerable grief for ghdl too.  
Tedious and messy.

- Brian