|
|
|
|
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 ). _______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
|
|
|
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
|
|
|
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
|
|
|
On 9/1/18 6:30 PM, Dmytro Lytovchenko 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
|
|
|
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
|
|
|
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
|
|
|
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 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 projectto implement an "Erlang processor" (via different presumably simplerVMs).Apart from the usual problems of synthesizing a processor, you alsohave to consider:- there's a lot of implicit state and semantics in the BEAMinstructions, 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 neednetworking supportMicrocoded HW implementations of LISP and Smalltalk were popular inthe 70s and early 80s, but were quickly replaced by SW running onRISCs with higher performance, lower cost, and quicker updates.I'm not sure for what use case a HW Erlang makes sense (except as anintellectual 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
|
|
|
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.
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 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 projectto implement an "Erlang processor" (via different presumably simplerVMs).Apart from the usual problems of synthesizing a processor, you alsohave to consider:- there's a lot of implicit state and semantics in the BEAMinstructions, 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 neednetworking supportMicrocoded HW implementations of LISP and Smalltalk were popular inthe 70s and early 80s, but were quickly replaced by SW running onRISCs with higher performance, lower cost, and quicker updates.I'm not sure for what use case a HW Erlang makes sense (except as anintellectual 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
|
|
Locked
