[erlang-questions] 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 
> <mfidelman@REDACTED <mailto:mfidelman@REDACTED>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180901/182bc205/attachment.htm>