Typed Architectures: architectural support for lightweight scripting

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

Typed Architectures: architectural support for lightweight scripting

Pierre Chapuis
I came across this paper [1] through the "morning paper" blog [2]. It describes a hardware architecture with support for dynamic types and uses Lua as an example. I thought it might interest some of the readers of the list.

[1] https://blog.acolyer.org/2017/05/22/typed-architectures-architectural-support-for-lightweight-scripting/
[2] https://pllab.github.io/papers/Typed-Architectures-Architectural-Support-for-Lightweight-Scripting/KIM-ET-AL_typed-architectures-architectural-support-for-lightweight-scripting_2017_ASPLOS.pdf

Reply | Threaded
Open this post in threaded view
|

Re: Typed Architectures: architectural support for lightweight scripting

彭 书呆
在 2017/5/27 17:51, Pierre Chapuis 写道:
> I came across this paper [1] through the "morning paper" blog [2]. It describes a hardware architecture with support for dynamic types and uses Lua as an example. I thought it might interest some of the readers of thelist.
>
> [1] https://blog.acolyer.org/2017/05/22/typed-architectures-architectural-support-for-lightweight-scripting/
> [2] https://pllab.github.io/papers/Typed-Architectures-Architectural-Support-for-Lightweight-Scripting/KIM-ET-AL_typed-architectures-architectural-support-for-lightweight-scripting_2017_ASPLOS.pdf
>

very interesting idea. the tagged registers and polymorphic instructions are very helpful
to fast execution paths of interpreters. a JIT compiler essentially does the same thing,
yet without the special hardware support. and in many cases an optimizing JIT compiler can
lift type guards out of inner loops, resulting better performance. nevertheless as the paper
stated, it mainly targets the resource restricted scenarios like IoT devices where JIT compilers
are not viable options.

I once had an idea of hardware accelerated Lua opcode interpreter. it serves as a co-processor
besides the general purpose processor or CPU. the accelerator has a windowed internal register
bank resembling the current stack frame of Lua functions. it only executes compiled Lua code.
I implemented the arithmetic operations, the numeric for loop, the conditional branch, and hash
table look up. other operations relies the software, like memory allocation, string hashing,
source code parser, internal register paging/swapping, calling to CFunction, etc.

unfortunately it turned out not to be usable in practice. the overhead was too high.


the paper also mentioned tagged data and polymorphic instructions, I once watched some videos[*]
about a interesting and novel processor design. the arithmetic instruction are type/width agnostic.
only the load and store instructions are type aware. the registers are tagged, then the ALU read
the tag to deal with different data width, even the the vector operations share the same opcode
with the scalar operations. and there is no global flag or condition register, instead they use
tag bits too. integer and floating point number use different opcodes, of course, since they are
different pipelines so the decoder need to discriminate them.

but I haven't heard any processor products from them, only had seen the talks. no idea whether
it exists only on papers.

   
[*] https://youtu.be/DZ8HN9Cnjhc

--
the nerdy Peng / 书呆彭 /