Threaded-code

[Happi]

----- Original Message -----
From: "Costel Vrinceanu" <cvrincea@REDACTED>


> Can someone explain what does 'threaded' in 'threaded-code emulation'
mean?

Kent Boortz once wrote an explanation of threaded code:
http://www-lp.doc.ic.ac.uk/UserPages/staff/ft/alp/net/impl/emulate.html

Basically, with directly threaded code each beam instruction is a pointer to
the C code in the emulator implementing that instruction. The emulator reads
the instruction and jumps to that address.


> I understand that the generated byte-code is modified when loaded in the
> emulator, but what/why 'threaded'?

The beam loader replaces each "external beam instruction" (instruction in
the beam file) with a pointer to code that implements the instruction. (In
fact the loader is much more complicated than that, the mapping from
external instructions to code in the emulator is not one-to-one, some
instructions are merged and other split.)

The reason is speed, you minimize the overhead of instruction dispatch by
having direct code pointers.

> Also, the BEAM spec says:
> "The BEAM system allows mixing threaded code emulation with compiling into
C"

This is probably from a very old BEAM spec. When BEAM was introduced you
could compile Erlang code to native code via C and link this to the BEAM
emulator.
This feature is long gone by now. Fortunately the HiPE compiler is
integrated into the Open Source (BEAM) Erlang system. With HiPE you can
compile Erlang to native code on SPARC and X86 and execute this together
with native code.

> Does this mean there is a mechanism other than BIFs for alternating
execution
> of BEAM instruction with execution of C functions/code segments?

Yes, (well I'm not sure that sentence meant that, but you can do it anyway)
see the discussion in this thread:

http://www.erlang.org/ml-archive/erlang-questions/200202/msg00000.html

You can for example use ports, linked in drivers, or BIFs.

/Erik