BEAM in hardware

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

BEAM in hardware

joe mcguckin
Does anyone know if the BEAM vm has ever been implemented directly in hardware (e.g. in an FPGA)?

Thanks,

Joe


Joe McGuckin
ViaNet Communications

[hidden email]
650-207-0372 cell
650-213-1302 office
650-969-2124 fax



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: BEAM in hardware

Dmytro Lytovchenko
There is no known hardware implementation because the original BEAM 158-instruction set is quite complex to load, parse and interpret, and the runtime part of hardware to support built-ins and data types would be pretty massive. But it might be possible if you simplify the opcode set, simplify the memory structure (to save on bit manipulations) similar to Python or Java memory model, and shrink it to something that is possible to hard-wire.

So yes, some _hobby_ work on that was done by me without a significant result: it turned out to be massive amount of work, without a commercial project, and without any particular goal - it becomes really hard to focus on the topic and to keep going. Essentially I worked on compressed instructions and reduced instruction set (here https://github.com/kvakvs/E4VM ), after some success I left the project, tried implementing a normal BEAM VM in software (https://github.com/kvakvs/ErlangRT ) and now trying another one for simplified memory model and compiling to machine code (https://github.com/kvakvs/ErlangAoT ).

On Sat, 1 Sep 2018 at 22:45, joe mcguckin <[hidden email]> wrote:
Does anyone know if the BEAM vm has ever been implemented directly in hardware (e.g. in an FPGA)?

Thanks,

Joe


Joe McGuckin
ViaNet Communications

[hidden email]
650-207-0372 cell
650-213-1302 office
650-969-2124 fax



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: BEAM in hardware

Miles Fidelman


On 9/1/18 5:06 PM, Dmytro Lytovchenko wrote:
> There is no known hardware implementation because the original BEAM
> 158-instruction set is quite complex to load, parse and interpret, and
> the runtime part of hardware to support built-ins and data types would
> be pretty massive. But it might be possible if you simplify the opcode
> set, simplify the memory structure (to save on bit manipulations)
> similar to Python or Java memory model, and shrink it to something
> that is possible to hard-wire.

Is it really any more complex than, implementing a CISC processor, or
something funky like a GPU or the old BBN Butterfly?  For that matter,
the old DG Nova had a pretty funky instruction set - looked a lot more
like microcode than a traditional ISA.

What about if you allow for microcode?  I remember working on microcode
to extend a MIL-STD-1750 processor, to do pulse train manipulation, for
electronic warfare applications (back in the day when 4mips was blinding
fast).  Or what about the LISP machines?

It doesn't seem out of the range of possibility - given a sufficiently
resourced team.  Now whether it makes economic sense, is a separate
question.

Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: BEAM in hardware

scott ribe
> On Sep 1, 2018, at 3:43 PM, Miles Fidelman <[hidden email]> wrote:
>
> Or what about the LISP machines?

Exactly. It could be done, but it makes no sense because of the economies of scale behind "standard architecture" CPUs.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: BEAM in hardware

Dmytro Lytovchenko
In reply to this post by Miles Fidelman


On Sat, 1 Sep 2018 at 23:44, Miles Fidelman <[hidden email]> wrote:


On 9/1/18 5:06 PM, Dmytro Lytovchenko wrote:
> There is no known hardware implementation because the original BEAM
> 158-instruction set is quite complex to load, parse and interpret, and
> the runtime part of hardware to support built-ins and data types would
> be pretty massive. But it might be possible if you simplify the opcode
> set, simplify the memory structure (to save on bit manipulations)
> similar to Python or Java memory model, and shrink it to something
> that is possible to hard-wire.

Is it really any more complex than, implementing a CISC processor, or
something funky like a GPU or the old BBN Butterfly?  For that matter,
the old DG Nova had a pretty funky instruction set - looked a lot more
like microcode than a traditional ISA.

That is my point. Of course anything that is implemented can be re-implemented, but there are resource limits to this complexity. To a large team with experience in chip design and production or even FPGA experience this might be totally possible, like "we just finished designing this beautiful Core i9 chip let's now take a break for a year and make a BEAM chip". But in real life such teams are rare, and I'm thinking of 1-3 person team and a _very_ limited budget, there's never enough time or working hands. Here to succeed one must take a lot of simplifications and considerations.
 
What about if you allow for microcode?  I remember working on microcode
to extend a MIL-STD-1750 processor, to do pulse train manipulation, for
electronic warfare applications (back in the day when 4mips was blinding
fast).  Or what about the LISP machines?

It doesn't seem out of the range of possibility - given a sufficiently
resourced team.  Now whether it makes economic sense, is a separate
question.

Making these two meet: The price of implementation vs. the available resources.

Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: BEAM in hardware

Miles Fidelman

On 9/1/18 6:30 PM, Dmytro Lytovchenko wrote:



On Sat, 1 Sep 2018 at 23:44, Miles Fidelman <[hidden email]> wrote:


On 9/1/18 5:06 PM, Dmytro Lytovchenko wrote:
> There is no known hardware implementation because the original BEAM
> 158-instruction set is quite complex to load, parse and interpret, and
> the runtime part of hardware to support built-ins and data types would
> be pretty massive. But it might be possible if you simplify the opcode
> set, simplify the memory structure (to save on bit manipulations)
> similar to Python or Java memory model, and shrink it to something
> that is possible to hard-wire.

Is it really any more complex than, implementing a CISC processor, or
something funky like a GPU or the old BBN Butterfly?  For that matter,
the old DG Nova had a pretty funky instruction set - looked a lot more
like microcode than a traditional ISA.

That is my point. Of course anything that is implemented can be re-implemented, but there are resource limits to this complexity. To a large team with experience in chip design and production or even FPGA experience this might be totally possible, like "we just finished designing this beautiful Core i9 chip let's now take a break for a year and make a BEAM chip". But in real life such teams are rare, and I'm thinking of 1-3 person team and a _very_ limited budget, there's never enough time or working hands. Here to succeed one must take a lot of simplifications and considerations.

Of course, in the old days - when we were talking ECL chips, and wire-wrapped prototypes, a 2-3 person team could do a LOT.  (Back in the early 1980s, I was on a team that designed & built high-performance avionic computers.  We had a number of small projects, funded by internal IR&D money, and some small research grants from the Air Force. 

These days, when we're talking building chips, it's another story. 

Though... I wonder what could be accomplished if one started with a chip that supported writeable microcode - like a Core2.  Hmmm.....

 
What about if you allow for microcode?  I remember working on microcode
to extend a MIL-STD-1750 processor, to do pulse train manipulation, for
electronic warfare applications (back in the day when 4mips was blinding
fast).  Or what about the LISP machines?

It doesn't seem out of the range of possibility - given a sufficiently
resourced team.  Now whether it makes economic sense, is a separate
question.

Making these two meet: The price of implementation vs. the available resources.

Might make a good PhD project, at a university that has access to military R&D funds.

Might also be worthwhile to a company that needs high-performance, massively concurrent processing.

Miles


-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: BEAM in hardware

ILYA Khlopotov-2
In reply to this post by joe mcguckin
There was a project from Ericsson http://www.presentica.com/ppt-presentation/ecomp-an-erlang-processor

BR,
iilyak

On September 1, 2018 1:33:01 PM PDT, joe mcguckin <[hidden email]> wrote:
Does anyone know if the BEAM vm has ever been implemented directly in hardware (e.g. in an FPGA)?

Thanks,

Joe


Joe McGuckin
ViaNet Communications

[hidden email]
650-207-0372 cell
650-213-1302 office
650-969-2124 fax





erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: BEAM in hardware

Michael Truog
On 09/01/2018 07:34 PM, ILYA wrote:
> There was a project from Ericsson
> http://www.presentica.com/ppt-presentation/ecomp-an-erlang-processor
That presentation was from the Erlang User Conference in 2000. Since
then it has become related to two papers at:

https://www.researchgate.net/publication/220760571
https://www.researchgate.net/publication/321538810

Best Regards,
Michael
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: BEAM in hardware

Richard Carlsson-3
In reply to this post by joe mcguckin
Not for the entire Beam, but here's a recent small scale attempt at going from Erlang down to Verilog:

        /Richard


Den lör 1 sep. 2018 kl 22:45 skrev joe mcguckin <[hidden email]>:
Does anyone know if the BEAM vm has ever been implemented directly in hardware (e.g. in an FPGA)?

Thanks,

Joe


Joe McGuckin
ViaNet Communications

[hidden email]
650-207-0372 cell
650-213-1302 office
650-969-2124 fax



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: BEAM in hardware

Mikael Pettersson-5
In reply to this post by joe mcguckin
On Sat, Sep 1, 2018 at 10:33 PM, joe mcguckin <[hidden email]> wrote:
> Does anyone know if the BEAM vm has ever been implemented directly in hardware (e.g. in an FPGA)?

Not the BEAM that I know of, but Ericsson has had at least one project
to implement an "Erlang processor" (via different presumably simpler
VMs).

Apart from the usual problems of synthesizing a processor, you also
have to consider:
- there's a lot of implicit state and semantics in the BEAM
instructions, so you'd have to duplicate things like processes,
dynamic memory allocation, garbage collection, exception handling,
message passing, process links, etc
- the BIFs, without which you can't do much, at a minimum you'd need
networking support

Microcoded HW implementations of LISP and Smalltalk were popular in
the 70s and early 80s, but were quickly replaced by SW running on
RISCs with higher performance, lower cost, and quicker updates.

I'm not sure for what use case a HW Erlang makes sense (except as an
intellectual exercise).
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: BEAM in hardware

Mike French
It probably makes more sense to do a software implementation on a platform that is somewhat isomorphic to the Erlang abstractions of independent processes and message passing - maybe VxWorks.

Whatever happened to the Parallella port?

Mike

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Mikael Pettersson
Sent: Sunday, September 02, 2018 1:18 PM
To: joe mcguckin <[hidden email]>
Cc: erlang-questions <[hidden email]>
Subject: Re: [erlang-questions] BEAM in hardware

On Sat, Sep 1, 2018 at 10:33 PM, joe mcguckin <[hidden email]> wrote:
> Does anyone know if the BEAM vm has ever been implemented directly in hardware (e.g. in an FPGA)?

Not the BEAM that I know of, but Ericsson has had at least one project to implement an "Erlang processor" (via different presumably simpler VMs).

Apart from the usual problems of synthesizing a processor, you also have to consider:
- there's a lot of implicit state and semantics in the BEAM instructions, so you'd have to duplicate things like processes, dynamic memory allocation, garbage collection, exception handling, message passing, process links, etc
- the BIFs, without which you can't do much, at a minimum you'd need networking support

Microcoded HW implementations of LISP and Smalltalk were popular in the 70s and early 80s, but were quickly replaced by SW running on RISCs with higher performance, lower cost, and quicker updates.

I'm not sure for what use case a HW Erlang makes sense (except as an intellectual exercise).
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: BEAM in hardware

Lloyd R. Prentice-2
In reply to this post by Mikael Pettersson-5
Hi All,

Some 30-odd years ago Chuck Moore, developer of Forth, turned his attention to chip design. He wrote his own chip-design CAD system in Forth and, subsequently designed and brought to silicon an impressive list of successful chips:

https://en.m.wikipedia.org/wiki/Charles_H._Moore

Chuck’s latest inspirations can be seen here:


The key to Chuck’s genius:  Pare the problem-at-hand down to it’s essence; seek starkest simplicity. This has kept him out of step with the computing mainstream throughout this career.

Best wishes,

LRP

Sent from my iPad

On Sep 2, 2018, at 6:17 AM, Mikael Pettersson <[hidden email]> wrote:

On Sat, Sep 1, 2018 at 10:33 PM, joe mcguckin <[hidden email]> wrote:
Does anyone know if the BEAM vm has ever been implemented directly in hardware (e.g. in an FPGA)?

Not the BEAM that I know of, but Ericsson has had at least one project
to implement an "Erlang processor" (via different presumably simpler
VMs).

Apart from the usual problems of synthesizing a processor, you also
have to consider:
- there's a lot of implicit state and semantics in the BEAM
instructions, so you'd have to duplicate things like processes,
dynamic memory allocation, garbage collection, exception handling,
message passing, process links, etc
- the BIFs, without which you can't do much, at a minimum you'd need
networking support

Microcoded HW implementations of LISP and Smalltalk were popular in
the 70s and early 80s, but were quickly replaced by SW running on
RISCs with higher performance, lower cost, and quicker updates.

I'm not sure for what use case a HW Erlang makes sense (except as an
intellectual exercise).
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: BEAM in hardware

joe mcguckin
 Chuck Moore’s ‘Moore Patent Portfolio’ has to be licensed by anyone manufacturing 
Microprocessors. Moore’s patents cover such essential  technologies like issuing more than one instruction per clock, multiple cores, embedded memory.

Pretty smart guy.



On Sep 2, 2018, at 6:57 AM, Lloyd R. Prentice <[hidden email]> wrote:

Hi All,

Some 30-odd years ago Chuck Moore, developer of Forth, turned his attention to chip design. He wrote his own chip-design CAD system in Forth and, subsequently designed and brought to silicon an impressive list of successful chips:

https://en.m.wikipedia.org/wiki/Charles_H._Moore

Chuck’s latest inspirations can be seen here:


The key to Chuck’s genius:  Pare the problem-at-hand down to it’s essence; seek starkest simplicity. This has kept him out of step with the computing mainstream throughout this career.

Best wishes,

LRP

Sent from my iPad

On Sep 2, 2018, at 6:17 AM, Mikael Pettersson <[hidden email]> wrote:

On Sat, Sep 1, 2018 at 10:33 PM, joe mcguckin <[hidden email]> wrote:
Does anyone know if the BEAM vm has ever been implemented directly in hardware (e.g. in an FPGA)?

Not the BEAM that I know of, but Ericsson has had at least one project
to implement an "Erlang processor" (via different presumably simpler
VMs).

Apart from the usual problems of synthesizing a processor, you also
have to consider:
- there's a lot of implicit state and semantics in the BEAM
instructions, so you'd have to duplicate things like processes,
dynamic memory allocation, garbage collection, exception handling,
message passing, process links, etc
- the BIFs, without which you can't do much, at a minimum you'd need
networking support

Microcoded HW implementations of LISP and Smalltalk were popular in
the 70s and early 80s, but were quickly replaced by SW running on
RISCs with higher performance, lower cost, and quicker updates.

I'm not sure for what use case a HW Erlang makes sense (except as an
intellectual exercise).
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions