Translating Haskell to VHDL. What approach to follow?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Translating Haskell to VHDL. What approach to follow?

Bugzilla from alfonso.acosta@gmail.com
Hi all,

As I wrote in the previous HLADPSA announcement, during the following
moths I'm going to write a translator from Haskell to VHDL in order to
accomplish my masters thesis goal.

The main requirement is managing to translate from a ForSyDe
(http://www.imit.kth.se/info/FOFU/ForSyDe/ ) specification which is
Haskell after all, to VHDL.

In order to get part of the work for free I decided to design the
translator as a compiler backend. The best option so far seems to be
Yhc's Core API (http://haskell.org/haskellwiki/Yhc/API/Core ), which
unfortunately lacks type information.

I discarded GHC due to the current "bit-rotted" state of External Core
(http://www.haskell.org/pipermail/haskell-cafe/2006-October/018786.html
) and higher complexity of its core representation (SystemFC).

I might have overlooked other approaches and/or intermediate
representations such as  GHC's C-- and STG (is it still used?).

I'd be pleased to hear any suggestions.

Thanks in advance,

Alfonso Acosta
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Translating Haskell to VHDL. What approach to follow?

Neil Mitchell
Hi

> In order to get part of the work for free I decided to design the
> translator as a compiler backend. The best option so far seems to be
> Yhc's Core API (http://haskell.org/haskellwiki/Yhc/API/Core ), which
> unfortunately lacks type information.

Can you mention what you need type information for? If it is to detect
higher order functions (as you have mentioned in IRC conversations
with me) then in about a week I am going to announce a Yhc.Core first
order transformation, which will remove that issue for you. In general
the lack of types in Yhc.Core has not proved a major issue for anyone
- if there is anyone who does absolutely require type information in
their intermediate language and therefore cannot use Yhc.Core, I'd be
very interested to hear from them.


> I discarded GHC due to the current "bit-rotted" state of External Core
> (http://www.haskell.org/pipermail/haskell-cafe/2006-October/018786.html
> ) and higher complexity of its core representation (SystemFC).

Igloo submitted a few patches in the last week to get GHC.Core working
again. It doesn't have the same infrastructure support as Yhc.Core,
but it does have the advantage of having the GHC team behind it.

> I'd be pleased to hear any suggestions.

I (obviously...) would like you to use Yhc.Core, if you could expand
on why that isn't appropriate for you then perhaps you'll either get
improvements into Yhc.Core or some hints from the GHC team :)

Thanks

Neil (ndm)
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Translating Haskell to VHDL. What approach to follow?

Bugzilla from alfonso.acosta@gmail.com
On 11/6/06, Neil Mitchell <[hidden email]> wrote:
> Can you mention what you need type information for? If it is to detect
> higher order functions (as you have mentioned in IRC conversations
> with me) then in about a week I am going to announce a Yhc.Core first
> order transformation, which will remove that issue for you. In general
> the lack of types in Yhc.Core has not proved a major issue for anyone
> - if there is anyone who does absolutely require type information in
> their intermediate language and therefore cannot use Yhc.Core, I'd be
> very interested to hear from them.

As you said, detecting the use of high order is one of the reasons as
it's not supported by VHDL.

I haven't yet planned how to achieve the translation but VHDL, unlike
Haskell, doesn't have type inference mechanisms. That means I need to
declare the interface of whatever I will translate each Yhc.Core
function to (i.e. VHDL Entities, Architectures, Functions ... )

>> I discarded GHC due to the current "bit-rotted" state of External Core

> Igloo submitted a few patches in the last week to get GHC.Core working
> again. It doesn't have the same infrastructure support as Yhc.Core,
> but it does have the advantage of having the GHC team behind it.

Does that change involve ExternalCore as well?

Either the way, those are great news. I'll have a look at it again.I
don't know much about SystemFC itself but I'm familiar with SystemF
and doesn't seem as friendly and easy to work with as Yhc.Core . I'll
give it a try anyway.


Thanks for the answer,

Alfonso Acosta (fons)
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Translating Haskell to VHDL. What approach to follow?

Simon Peyton Jones
In reply to this post by Bugzilla from alfonso.acosta@gmail.com
| In order to get part of the work for free I decided to design the
| translator as a compiler backend. The best option so far seems to be
| Yhc's Core API (http://haskell.org/haskellwiki/Yhc/API/Core ), which
| unfortunately lacks type information.
|
| I discarded GHC due to the current "bit-rotted" state of External Core
|
(http://www.haskell.org/pipermail/haskell-cafe/2006-October/018786.html
| ) and higher complexity of its core representation (SystemFC).

Yhc is a great, so don't let me stop you using it... but I can't resist
explaining why FC is the way it is.  There is a real tension here
between simplicity and types.  The reason that GHC uses FC as its
intermediate language is precisely because FC is the simplest *typed*
language we know that can serve as a target for Haskell.  If you drop
the types, you certainly can use a simpler language!

However, you only pay for what you use; for example, if you don't use
newtypes, GADT's, associated types, you won't see any coercions.

It's true that the ExtCore rep is somewhat bit-rotted, but the only
thing missing to get Core *output* is someone to beef up the pretty
printer.  I'd do it myself, except that there is a *design* task to do,
namely to fix the concrete syntax for some of FC's constructs.  One
could choose anything, but it'd be good to choose a syntax that is easy
to parse.  Once the syntax is designed, it'd take an hour or two to make
GHC emit it.  (There's a separate job to make GHC parse and typecheck
ExtCore as its source program, but you don't need that.)

Aaron Tomb has offered to become the maintainer for External Core; I'm
sure he'd be interested in having a "customer".  

Simon
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Translating Haskell to VHDL. What approach to follow?

Neil Mitchell
Hi

> I haven't yet planned how to achieve the translation but VHDL, unlike
> Haskell, doesn't have type inference mechanisms. That means I need to
> declare the interface of whatever I will translate each Yhc.Core
> function to (i.e. VHDL Entities, Architectures, Functions ... )

Can you explain more about the "declare the interface" remark? I
suspect this can be acheived with Yhc using the signatures from the
.hi files, or embeding the information with our "typerep" Haskell
extension.

> It's true that the ExtCore rep is somewhat bit-rotted, but the only
> thing missing to get Core *output* is someone to beef up the pretty
> printer.  I'd do it myself, except that there is a *design* task to do,
> namely to fix the concrete syntax for some of FC's constructs.  One
> could choose anything, but it'd be good to choose a syntax that is easy
> to parse.  Once the syntax is designed, it'd take an hour or two to make
> GHC emit it.  (There's a separate job to make GHC parse and typecheck
> ExtCore as its source program, but you don't need that.)

For a reference point, I debated what the Yhc Core language should
look like for a while. Then I gave up, grabbed a copy of DrIFT, adding
"deriving Binary" annotations and was done. There is a concrete binary
data type that represents Yhc.Core, but I have no idea what it is, and
I certainly don't support access to it. There is a Haskell library
which can load a Yhc.Core file, manipulate it, write it out etc -
removing the need for a concrete syntax. We have a pretty printer, but
since thats a one way mapping its much easier, we just made it look as
much like Haskell as possible (no Z encoding etc).

Thanks

Neil
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Translating Haskell to VHDL. What approach to follow?

Bugzilla from alfonso.acosta@gmail.com
On 11/6/06, Neil Mitchell <[hidden email]> wrote:
> Can you explain more about the "declare the interface" remark? I
> suspect this can be acheived with Yhc using the signatures from the
> .hi files, or embeding the information with our "typerep" Haskell
> extension.

I think you're correctly suspecting it.

What I meant is that, like with every structured programming language
(that I know about at least) all VHDL functions and procedure
declarations (Entities & Architectures as well) include a mandatory
interface declaration which includes the type of its parameters and
possible return value.

That implies I need a way to infere or directly obtain the types of
the functions used in the core representation. That as you said, can
probably be done by means of the .hi files or the typerep extension
you mentioned. I'll try to have a look at both options. Any good
documentation pointers?

I think that should be all the type information required for the translation.

> Yhc is a great, so don't let me stop you using it... but I can't resist
> explaining why FC is the way it is.  There is a real tension here
> between simplicity and types.  The reason that GHC uses FC as its
> intermediate language is precisely because FC is the simplest *typed*
> language we know that can serve as a target for Haskell.  If you drop
> the types, you certainly can use a simpler language!

I'm sure SystemFC wasn't arbitrarily chosen, and works well for its
main purpose (being GHC's intermediate language). On the other hand it
can be a bit complicated if it is used as the input of backend whose
goal is translating to a another another high abstraction language.

For my planned backend, it _seems_ to be enough to use a desugarized
version of the initial source file as input and being able to
obtain/infer the type its the functions.

That doesn't mean I have already discarded GHC, I recorsidered it
again after reading that there is some work being done to update it.

Does http://www.haskell.org/ghc/docs/papers/core.ps.gz still apply?
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Translating Haskell to VHDL. What approach to follow?

Neil Mitchell
Hi

> That implies I need a way to infere or directly obtain the types of
> the functions used in the core representation. That as you said, can
> probably be done by means of the .hi files or the typerep extension
> you mentioned. I'll try to have a look at both options. Any good
> documentation pointers?

For .hi files just compile it with Yhc and take a look at the .hi file
it creates, they are plain text. If they are top level functions
(which they certainly are, I guess) this should be all you need.
Another approach is to get the type information out of Hugs with the
:t command line prod. I've done this before in another project.

Thanks

Neil
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Translating Haskell to VHDL. What approach to follow?

Bugzilla from alfonso.acosta@gmail.com
> For .hi files just compile it with Yhc and take a look at the .hi file
> it creates, they are plain text. If they are top level functions
> (which they certainly are, I guess) this should be all you need.
> Another approach is to get the type information out of Hugs with the
> :t command line prod. I've done this before in another project.

Sorry for the delay answering. I didn't (and still won't) have access
to the Internet for a few days but Ill try it and tell you if it
worked once I'm back to normality.

Thanks,

Alfonso Acosta
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Translating Haskell to VHDL. What approach to follow?

Bugzilla from alfonso.acosta@gmail.com
After considering the different options (specially Yhc.Core) I decided
to go for Embedded Compiling [1] + Observable Sharing[2]  to translate
from ForSyDe[3] to VHDL[4] instead of making a whole Haskell-Compiler
backend.

Creating a backend would fit a more ambitious goal: translating any
haskell source file to VHDL, and of course would be more difficult to
approach.

The drawback of the Embedded Compiler approach is that ForSyDe will
need to be adapted. But instead the translation would be quite easy to
make and what is more important, a lot more maintainable due to being
independent of external tools and embedded in the library itself.

Thanks a lot for your suggestions. Specially to Neil who is
fortunately always open to help.

References
[1] http://haskell.org/haskellwiki/Research_papers/Domain_specific_languages
[2] http://www.cs.chalmers.se/~koen/pubs/entry-asian99-lava.html
[3] http://www.imit.kth.se/info/FOFU/ForSyDe/
[4] http://en.wikipedia.org/wiki/VHDL

On 11/12/06, Alfonso Acosta <[hidden email]> wrote:

> > For .hi files just compile it with Yhc and take a look at the .hi file
> > it creates, they are plain text. If they are top level functions
> > (which they certainly are, I guess) this should be all you need.
> > Another approach is to get the type information out of Hugs with the
> > :t command line prod. I've done this before in another project.
>
> Sorry for the delay answering. I didn't (and still won't) have access
> to the Internet for a few days but Ill try it and tell you if it
> worked once I'm back to normality.
>
> Thanks,
>
> Alfonso Acosta
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe