diff options
Diffstat (limited to 'erts/doc/src/erl_ext_dist.xml')
| -rw-r--r-- | erts/doc/src/erl_ext_dist.xml | 1014 |
1 files changed, 1014 insertions, 0 deletions
diff --git a/erts/doc/src/erl_ext_dist.xml b/erts/doc/src/erl_ext_dist.xml new file mode 100644 index 0000000000..c2d58d1ef1 --- /dev/null +++ b/erts/doc/src/erl_ext_dist.xml @@ -0,0 +1,1014 @@ +<?xml version="1.0" encoding="iso-8859-1" ?> +<!DOCTYPE chapter SYSTEM "chapter.dtd"> + +<chapter> + <header> + <copyright> + <year>2007</year> + <year>2007</year> + <holder>Ericsson AB, All Rights Reserved</holder> + </copyright> + <legalnotice> + The contents of this file are subject to the Erlang Public License, + Version 1.1, (the "License"); you may not use this file except in + compliance with the License. You should have received a copy of the + Erlang Public License along with this software. If not, it can be + retrieved online at http://www.erlang.org/. + + Software distributed under the License is distributed on an "AS IS" + basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See + the License for the specific language governing rights and limitations + under the License. + + The Initial Developer of the Original Code is Ericsson AB. + </legalnotice> + + <title>External Term Format</title> + <prepared>Kenneth</prepared> + <docno></docno> + <date>2007-09-21</date> + <rev>PA1</rev> + <file>erl_ext_dist.xml</file> + </header> + + <section> + <title>Introduction</title> + <p> + The external term format is mainly used in the distribution + mechanism of Erlang. + </p> + <p> + Since Erlang has a fixed number of types, there is no need for a + programmer to define a specification for the external format used + within some application. + All Erlang terms has an external representation and the interpretation + of the different terms are application specific. + </p> + <p> + In Erlang the BIF <seealso marker="erts:erlang#term_to_binary/1">term_to_binary/1,2</seealso> is used to convert a + term into the external format. + To convert binary data encoding a term the BIF + <seealso marker="erts:erlang#binary_to_term/1"> + binary_to_term/1 + </seealso> + is used. + </p> + <p> + The distribution does this implicitly when sending messages across + node boundaries. + </p> + <marker id="overall_format"/> + <p> + The overall format of the term format is: + </p> + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">1</cell> + <cell align="center">N</cell> + </row> + <row> + <cell align="center"><c>131</c></cell> + <cell align="center"><c>Tag</c></cell> + <cell align="center"><c>Data</c></cell> + </row> + <tcaption></tcaption></table> + <note> + <p> + When messages are + <seealso marker="erl_dist_protocol#connected_nodes">passed between + connected nodes</seealso> and a + <seealso marker="#distribution_header">distribution + header</seealso> is used, the first byte containing the version + number (131) is omitted from the terms that follow the distribution + header. This since + the version number is implied by the version number in the + distribution header. + </p> + </note> + <p> + A compressed term looks like this: + </p> + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">1</cell> + <cell align="center">4</cell> + <cell align="center">N</cell> + </row> + <row> + <cell align="center">131</cell> + <cell align="center">80</cell> + <cell align="center">UncompressedSize</cell> + <cell align="center">Zlib-compressedData</cell> + </row> + <tcaption></tcaption></table> + <p> + Uncompressed Size (unsigned 32 bit integer in big-endian byte order) + is the size of the data before it was compressed. + The compressed data has the following format when it has been + expanded: + </p> + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">Uncompressed Size</cell> + </row> + <row> + <cell align="center">Tag</cell> + <cell align="center">Data</cell> + </row> + <tcaption></tcaption></table> + </section> + + <section> + <marker id="distribution_header"/> + <title>Distribution header</title> + <p> + As of erts version 5.7.2 the old atom cache protocol was + dropped and a new one was introduced. This atom cache protocol + introduced the distribution header. Nodes with erts versions + earlier than 5.7.2 can still communicate with new nodes, + but no distribution header and no atom cache will be used.</p> + <p> + The distribution header currently only contains an atom cache + reference section, but could in the future contain more + information. The distribution header precedes one or more Erlang + terms on the external format. For more information see the + documentation of the + <seealso marker="erl_dist_protocol#connected_nodes">protocol between + connected nodes</seealso> in the + <seealso marker="erl_dist_protocol">distribution protocol</seealso> + documentation. + </p> + <p> + <seealso marker="#ATOM_CACHE_REF">ATOM_CACHE_REF</seealso> + entries with corresponding <c>AtomCacheReferenceIndex</c> in terms + encoded on the external format following a distribution header refers + to the atom cache references made in the distribution header. The range + is 0 <= <c>AtomCacheReferenceIndex</c> < 255, i.e., at most 255 + different atom cache references from the following terms can be made. + </p> + <p> + The distribution header format is: + </p> + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">1</cell> + <cell align="center">1</cell> + <cell align="center">NumberOfAtomCacheRefs/2+1 | 0</cell> + <cell align="center">N | 0</cell> + </row> + <row> + <cell align="center"><c>131</c></cell> + <cell align="center"><c>68</c></cell> + <cell align="center"><c>NumberOfAtomCacheRefs</c></cell> + <cell align="center"><c>Flags</c></cell> + <cell align="center"><c>AtomCacheRefs</c></cell> + </row> + <tcaption></tcaption></table> + <p> + <c>Flags</c> consists of <c>NumberOfAtomCacheRefs/2+1</c> bytes, + unless <c>NumberOfAtomCacheRefs</c> is <c>0</c>. If + <c>NumberOfAtomCacheRefs</c> is <c>0</c>, <c>Flags</c> and + <c>AtomCacheRefs</c> are omitted. Each atom cache reference have + a half byte flag field. Flags corresponding to a specific + <c>AtomCacheReferenceIndex</c>, are located in flag byte number + <c>AtomCacheReferenceIndex/2</c>. Flag byte 0 is the first byte + after the <c>NumberOfAtomCacheRefs</c> byte. Flags for an even + <c>AtomCacheReferenceIndex</c> are located in the least significant + half byte and flags for an odd <c>AtomCacheReferenceIndex</c> are + located in the most significant half byte. + </p> + <p> + The flag field of an atom cache reference has the following + format: + </p> + <table align="left"> + <row> + <cell align="center">1 bit</cell> + <cell align="center">3 bits</cell> + </row> + <row> + <cell align="center"><c>NewCacheEntryFlag</c></cell> + <cell align="center"><c>SegmentIndex</c></cell> + </row> + <tcaption></tcaption></table> + <p> + The most significant bit is the <c>NewCacheEntryFlag</c>. If set, + the corresponding cache reference is new. The three least + significant bits are the <c>SegmentIndex</c> of the corresponding + atom cache entry. An atom cache consists of 8 segments each of size + 256, i.e., an atom cache can contain 2048 entries. + </p> + <p> + After flag fields for atom cache references, another half byte flag + field is located which has the following format: + </p> + <table align="left"> + <row> + <cell align="center">3 bits</cell> + <cell align="center">1 bit</cell> + </row> + <row> + <cell align="center"><c>CurrentlyUnused</c></cell> + <cell align="center"><c>LongAtoms</c></cell> + </row> + <tcaption></tcaption></table> + <p> + The least significant bit in that half byte is the <c>LongAtoms</c> + flag. If it is set, 2 bytes are used for atom lengths instead of + 1 byte in the distribution header. However, the current emulator + cannot handle long atoms, so it will currently always be 0. + </p> + <p> + After the <c>Flags</c> field follow the <c>AtomCacheRefs</c>. The + first <c>AtomCacheRef</c> is the one corresponding to + <c>AtomCacheReferenceIndex</c> 0. Higher indices follows + in sequence up to index <c>NumberOfAtomCacheRefs - 1</c>. + </p> + <p> + If the <c>NewCacheEntryFlag</c> for the next <c>AtomCacheRef</c> has + been set, a <c>NewAtomCacheRef</c> on the following format will follow: + </p> + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">1 | 2</cell> + <cell align="center">Length</cell> + </row> + <row> + <cell align="center"><c>InternalSegmentIndex</c></cell> + <cell align="center"><c>Length</c></cell> + <cell align="center"><c>AtomText</c></cell> + </row> + <tcaption></tcaption></table> + <p> + <c>InternalSegmentIndex</c> together with the <c>SegmentIndex</c> + completely identify the location of an atom cache entry in the + atom cache. <c>Length</c> is number of one byte characters that + the atom text consists of. Length is a two byte big endian integer + if the <c>LongAtoms</c> flag has been set, otherwise a one byte + integer. Subsequent <c>CachedAtomRef</c>s with the same + <c>SegmentIndex</c> and <c>InternalSegmentIndex</c> as this + <c>NewAtomCacheRef</c> will refer to this atom until a new + <c>NewAtomCacheRef</c> with the same <c>SegmentIndex</c> + and <c>InternalSegmentIndex</c> appear. + </p> + <p> + If the <c>NewCacheEntryFlag</c> for the next <c>AtomCacheRef</c> + has not been set, a <c>CachedAtomRef</c> on the following format + will follow: + </p> + <table align="left"> + <row> + <cell align="center">1</cell> + </row> + <row> + <cell align="center"><c>InternalSegmentIndex</c></cell> + </row> + <tcaption></tcaption></table> + <p> + <c>InternalSegmentIndex</c> together with the <c>SegmentIndex</c> + identify the location of the atom cache entry in the atom cache. + The atom corresponding to this <c>CachedAtomRef</c> is the + latest <c>NewAtomCacheRef</c> preceding this <c>CachedAtomRef</c> + in another previously passed distribution header. + </p> + </section> + + <section> + <marker id="ATOM_CACHE_REF"/> + <title>ATOM_CACHE_REF</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">1</cell> + </row> + <row> + <cell align="center"><c>82</c></cell> + <cell align="center"><c>AtomCacheReferenceIndex</c></cell> + </row> + <tcaption></tcaption></table> + <p> + Refers to the atom with <c>AtomCacheReferenceIndex</c> in the + <seealso marker="#distribution_header">distribution header</seealso>. + </p> + </section> + + <section> + <marker id="SMALL_INTEGER_EXT"/> + <title>SMALL_INTEGER_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">1</cell> + </row> + <row> + <cell align="center">97</cell> + <cell align="center">Int</cell> + </row> + <tcaption></tcaption></table> + <p> + Unsigned 8 bit integer. + </p> + </section> + + <section> + <marker id="INTEGER_EXT"/> + <title>INTEGER_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">4</cell> + </row> + <row> + <cell align="center">98</cell> + <cell align="center">Int</cell> + </row> + <tcaption></tcaption></table> + <p> + Signed 32 bit integer in big-endian format (i.e. MSB first) + </p> + </section> + + <section> + <marker id="FLOAT_EXT"/> + <title>FLOAT_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">31</cell> + </row> + <row> + <cell align="center">99</cell> + <cell align="center">Float String</cell> + </row> + <tcaption></tcaption></table> + <p> + A float is stored in string format. the format used in sprintf to + format the float is "%.20e" + (there are more bytes allocated than necessary). + To unpack the float use sscanf with format "%lf". + </p> + <p> + This term is used in minor version 0 of the external format; + it has been superseded by + <seealso marker="#NEW_FLOAT_EXT"> + NEW_FLOAT_EXT + </seealso>. + </p> + </section> + + <section> + <marker id="ATOM_EXT"/> + <title>ATOM_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">2</cell> + <cell align="center">Len</cell> + </row> + <row> + <cell align="center"><c>100</c></cell> + <cell align="center"><c>Len</c></cell> + <cell align="center"><c>AtomName</c></cell> + </row> + <tcaption></tcaption></table> + <p> + An atom is stored with a 2 byte unsigned length in big-endian order, + followed by <c>Len</c> numbers of 8 bit characters that forms the + <c>AtomName</c>. + Note: The maximum allowed value for <c>Len</c> is 255. + </p> + </section> + + <section> + <marker id="REFERENCE_EXT"/> + <title>REFERENCE_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">N</cell> + <cell align="center">4</cell> + <cell align="center">1</cell> + </row> + <row> + <cell align="center"><c>101</c></cell> + <cell align="center"><c>Node</c></cell> + <cell align="center"><c>ID</c></cell> + <cell align="center"><c>Creation</c></cell> + </row> + <tcaption></tcaption></table> + <p> + Encode a reference object (an object generated with <c>make_ref/0</c>). + The <c>Node</c> term is an encoded atom, i.e. + <seealso marker="#ATOM_EXT">ATOM_EXT</seealso>, + <seealso marker="#SMALL_ATOM_EXT">SMALL_ATOM_EXT</seealso> or + <seealso marker="#ATOM_CACHE_REF">ATOM_CACHE_REF</seealso>. + The <c>ID</c> field contains a big-endian + unsigned integer, + but <em>should be regarded as uninterpreted data</em> + since this field is node specific. + <c>Creation</c> is a byte containing a node serial number that + makes it possible to separate old (crashed) nodes from a new one. + </p> + <p> + In <c>ID</c>, only 18 bits are significant; the rest should be 0. + In <c>Creation</c>, only 2 bits are significant; the rest should be 0. + + See <seealso marker="#NEW_REFERENCE_EXT">NEW_REFERENCE_EXT</seealso>. + </p> + </section> + + <section> + <marker id="PORT_EXT"/> + <title>PORT_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">N</cell> + <cell align="center">4</cell> + <cell align="center">1</cell> + </row> + <row> + <cell align="center"><c>102</c></cell> + <cell align="center"><c>Node</c></cell> + <cell align="center"><c>ID</c></cell> + <cell align="center"><c>Creation</c></cell> + </row> + <tcaption></tcaption></table> + <p> + Encode a port object (obtained form <c>open_port/2</c>). + The <c>ID</c> is a node specific identifier for a local port. + Port operations are not allowed across node boundaries. + The <c>Creation</c> works just like in + <seealso marker="#REFERENCE_EXT">REFERENCE_EXT</seealso>. + </p> + </section> + + <section> + <marker id="PID_EXT"/> + <title>PID_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">N</cell> + <cell align="center">4</cell> + <cell align="center">4</cell> + <cell align="center">1</cell> + </row> + <row> + <cell align="center"><c>103</c></cell> + <cell align="center"><c>Node</c></cell> + <cell align="center"><c>ID</c></cell> + <cell align="center"><c>Serial</c></cell> + <cell align="center"><c>Creation</c></cell> + </row> + <tcaption></tcaption></table> + <p> + Encode a process identifier object (obtained from <c>spawn/3</c> or + friends). + The <c>ID</c> and <c>Creation</c> fields works just like in + <seealso marker="#REFERENCE_EXT">REFERENCE_EXT</seealso>, while + the <c>Serial</c> field is used to improve safety. + + In <c>ID</c>, only 15 bits are significant; the rest should be 0. + </p> + + </section> + + <section> + <marker id="SMALL_TUPLE_EXT"/> + <title>SMALL_TUPLE_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">1</cell> + <cell align="center">N</cell> + </row> + <row> + <cell align="center">104</cell> + <cell align="center">Arity</cell> + <cell align="center">Elements</cell> + </row> + <tcaption></tcaption></table> + <p> + <c>SMALL_TUPLE_EXT</c> encodes a tuple. The <c>Arity</c> + field is an unsigned byte that determines how many element + that follows in the <c>Elements</c> section. + </p> + </section> + + <section> + <marker id="LARGE_TUPLE_EXT"/> + <title>LARGE_TUPLE_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">4</cell> + <cell align="center">N</cell> + </row> + <row> + <cell align="center">105</cell> + <cell align="center">Arity</cell> + <cell align="center">Elements</cell> + </row> + <tcaption></tcaption></table> + <p> + Same as + <seealso marker="#SMALL_TUPLE_EXT">SMALL_TUPLE_EXT</seealso> + with the exception that <c>Arity</c> is an + unsigned 4 byte integer in big endian format. + </p> + </section> + + <section> + <marker id="NIL_EXT"/> + <title>NIL_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + </row> + <row> + <cell align="center">106</cell> + </row> + <tcaption></tcaption></table> + <p> + The representation for an empty list, i.e. the Erlang syntax <c>[]</c>. + </p> + </section> + + <section> + <marker id="STRING_EXT"/> + <title>STRING_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">2</cell> + <cell align="center">Len</cell> + </row> + <row> + <cell align="center">107</cell> + <cell align="center">Length</cell> + <cell align="center">Characters</cell> + </row> + <tcaption></tcaption></table> + <p> + String does NOT have a corresponding Erlang representation, + but is an optimization for sending lists of bytes (integer in + the range 0-255) more efficiently over the distribution. + Since the <c>Length</c> field is an unsigned 2 byte integer + (big endian), implementations must make sure that lists longer than + 65535 elements are encoded as + <seealso marker="#LIST_EXT">LIST_EXT</seealso>. + </p> + + </section> + + <section> + <marker id="LIST_EXT"/> + <title>LIST_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">4</cell> + <cell align="center"> </cell> + <cell align="center"> </cell> + </row> + <row> + <cell align="center">108</cell> + <cell align="center">Length</cell> + <cell align="center">Elements</cell> + <cell align="center">Tail</cell> + </row> + <tcaption></tcaption></table> + + <p> + <c>Length</c> is the number of elements that follows in the + <c>Elements</c> section. <c>Tail</c> is the final tail of + the list; it is + <seealso marker="#NIL_EXT">NIL_EXT</seealso> + for a proper list, but may be anything type if the list is + improper (for instance <c>[a|b]</c>). + </p> + </section> + + <section> + <marker id="BINARY_EXT"/> + <title>BINARY_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">4</cell> + <cell align="center">Len</cell> + </row> + <row> + <cell align="center">109</cell> + <cell align="center">Len</cell> + <cell align="center">Data</cell> + </row> + <tcaption></tcaption></table> + <p> + Binaries are generated with bit syntax expression or with + <seealso marker="erts:erlang#list_to_binary/1">list_to_binary/1</seealso>, + <seealso marker="erts:erlang#term_to_binary/1">term_to_binary/1</seealso>, + or as input from binary ports. + The <c>Len</c> length field is an unsigned 4 byte integer + (big endian). + </p> + </section> + + <section> + <marker id="SMALL_BIG_EXT"/> + <title>SMALL_BIG_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">1</cell> + <cell align="center">1</cell> + <cell align="center">n</cell> + </row> + <row> + <cell align="center">110</cell> + <cell align="center">n</cell> + <cell align="center">Sign</cell> + <cell align="center">d(0) ... d(n-1)</cell> + </row> + <tcaption></tcaption></table> + <p> + Bignums are stored in unary form with a <c>Sign</c> byte + that is 0 if the binum is positive and 1 if is negative. The + digits are stored with the LSB byte stored first. To + calculate the integer the following formula can be used:<br/> + + B = 256<br/> + (d0*B^0 + d1*B^1 + d2*B^2 + ... d(N-1)*B^(n-1)) + </p> + </section> + + <section> + <marker id="LARGE_BIG_EXT"/> + <title>LARGE_BIG_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">4</cell> + <cell align="center">1</cell> + <cell align="center">n</cell> + </row> + <row> + <cell align="center">111</cell> + <cell align="center">n</cell> + <cell align="center">Sign</cell> + <cell align="center">d(0) ... d(n-1)</cell> + </row> + <tcaption></tcaption></table> + <p> + Same as <seealso marker="#SMALL_BIG_EXT">SMALL_BIG_EXT</seealso> + with the difference that the length field + is an unsigned 4 byte integer. + </p> + + </section> + + <section> + <marker id="NEW_REFERENCE_EXT"/> + <title>NEW_REFERENCE_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">2</cell> + <cell align="center">N</cell> + <cell align="center">1</cell> + <cell align="center">N'</cell> + </row> + <row> + <cell align="center">114</cell> + <cell align="center">Len</cell> + <cell align="center">Node</cell> + <cell align="center">Creation</cell> + <cell align="center">ID ...</cell> + </row> + <tcaption></tcaption></table> + <p> + Node and Creation are as in + <seealso marker="#REFERENCE_EXT">REFERENCE_EXT</seealso>. + </p> + <p> + <c>ID</c> contains a sequence of big-endian unsigned integers + (4 bytes each, so <c>N'</c> is a multiple of 4), + but should be regarded as uninterpreted data. + </p> + <p> + <c>N'</c> = 4 * <c>Len</c>. + </p> + <p> + In the first word (four bytes) of <c>ID</c>, only 18 bits are + significant, the rest should be 0. + In <c>Creation</c>, only 2 bits are significant, + the rest should be 0. + </p> + <p> + NEW_REFERENCE_EXT was introduced with distribution version 4. + In version 4, <c>N'</c> should be at most 12. + </p> + <p> + See <seealso marker="#REFERENCE_EXT">REFERENCE_EXT</seealso>). + </p> + </section> + + <section> + <marker id="SMALL_ATOM_EXT"/> + <title>SMALL_ATOM_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">1</cell> + <cell align="center">Len</cell> + </row> + <row> + <cell align="center"><c>115</c></cell> + <cell align="center"><c>Len</c></cell> + <cell align="center"><c>AtomName</c></cell> + </row> + <tcaption></tcaption></table> + <p> + An atom is stored with a 1 byte unsigned length, + followed by <c>Len</c> numbers of 8 bit characters that + forms the <c>AtomName</c>. Longer atoms can be represented + by <seealso marker="#ATOM_EXT">ATOM_EXT</seealso>. <em>Note</em> + the <c>SMALL_ATOM_EXT</c> was introduced in erts version 5.7.2 and + require a small atom distribution flag exchanged in the distribution + handshake. + </p> + </section> + + <section> + <marker id="FUN_EXT"/> + <title>FUN_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">4</cell> + <cell align="center">N1</cell> + <cell align="center">N2</cell> + <cell align="center">N3</cell> + <cell align="center">N4</cell> + <cell align="center">N5</cell> + </row> + <row> + <cell align="center">117</cell> + <cell align="center">NumFree</cell> + <cell align="center">Pid</cell> + <cell align="center">Module</cell> + <cell align="center">Index</cell> + <cell align="center">Uniq</cell> + <cell align="center">Free vars ...</cell> + </row> + <tcaption></tcaption></table> + <taglist> + <tag><c>Pid</c></tag> + <item> + is a process identifier as in + <seealso marker="#PID_EXT">PID_EXT</seealso>. + It represents the process in which the fun was created. + </item> + <tag><c>Module</c></tag> + <item> + is an encoded as an atom, using + <seealso marker="#ATOM_EXT">ATOM_EXT</seealso>, + <seealso marker="#SMALL_ATOM_EXT">SMALL_ATOM_EXT</seealso> + or <seealso marker="#ATOM_CACHE_REF">ATOM_CACHE_REF</seealso>. + This is the module that the fun is implemented in. + </item> + <tag><c>Index</c></tag> + <item> + is an integer encoded using + <seealso marker="#SMALL_INTEGER_EXT">SMALL_INTEGER_EXT</seealso> + or <seealso marker="#INTEGER_EXT">INTEGER_EXT</seealso>. + It is typically a small index into the module's fun table. + </item> + <tag><c>Uniq</c></tag> + <item> + is an integer encoded using + <seealso marker="#SMALL_INTEGER_EXT">SMALL_INTEGER_EXT</seealso> or + <seealso marker="#INTEGER_EXT">INTEGER_EXT</seealso>. + <c>Uniq</c> is the hash value of the parse for the fun. + </item> + <tag><c>Free vars</c></tag> + <item> + is <c>NumFree</c> number of terms, each one encoded according + to its type. + </item> + </taglist> + </section> + + <section> + <marker id="NEW_FUN_EXT"/> + <title>NEW_FUN_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">4</cell> + <cell align="center">1</cell> + <cell align="center">16</cell> + <cell align="center">4</cell> + <cell align="center">4</cell> + <cell align="center">N1</cell> + <cell align="center">N2</cell> + <cell align="center">N3</cell> + <cell align="center">N4</cell> + <cell align="center">N5</cell> + </row> + <row> + <cell align="center">112</cell> + <cell align="center">Size</cell> + <cell align="center">Arity</cell> + <cell align="center">Uniq</cell> + <cell align="center">Index</cell> + <cell align="center">NumFree</cell> + <cell align="center">Module</cell> + <cell align="center">OldIndex</cell> + <cell align="center">OldUniq</cell> + <cell align="center">Pid</cell> + <cell align="center">Free Vars</cell> + </row> + <tcaption></tcaption></table> + <p> + This is the new encoding of internal funs: <c>fun F/A</c> and + <c>fun(Arg1,..) -> ... end</c>. + </p> + <taglist> + <tag><c>Size</c></tag> + <item> + is the total number of bytes, including the <c>Size</c> field. + </item> + <tag><c>Arity</c></tag> + <item> + is the arity of the function implementing the fun. + </item> + <tag><c>Uniq</c></tag> + <item> + is the 16 bytes MD5 of the significant parts of the Beam file. + </item> + <tag><c>Index</c></tag> + <item> + is an index number. Each fun within a module has an unique + index. <c>Index</c> is stored in big-endian byte order. + </item> + <tag><c>NumFree</c></tag> + <item> + is the number of free variables. + </item> + <tag><c>Module</c></tag> + <item> + is an encoded as an atom, using + <seealso marker="#ATOM_EXT">ATOM_EXT</seealso>, + <seealso marker="#SMALL_ATOM_EXT">SMALL_ATOM_EXT</seealso> or + <seealso marker="#ATOM_CACHE_REF">ATOM_CACHE_REF</seealso>. + This is the module that the fun is implemented in. + </item> + <tag><c>OldIndex</c></tag> + <item> + is an integer encoded using + <seealso marker="#SMALL_INTEGER_EXT">SMALL_INTEGER_EXT</seealso> + or <seealso marker="#INTEGER_EXT">INTEGER_EXT</seealso>. + It is typically a small index into the module's fun table. + </item> + <tag><c>OldUniq</c></tag> + <item> + is an integer encoded using + <seealso marker="#SMALL_INTEGER_EXT">SMALL_INTEGER_EXT</seealso> + or + <seealso marker="#INTEGER_EXT">INTEGER_EXT</seealso>. + <c>Uniq</c> is the hash value of the parse tree for the fun. + </item> + <tag><c>Pid</c></tag> + <item> + is a process identifier as in + <seealso marker="#PID_EXT">PID_EXT</seealso>. + It represents the process in which + the fun was created. + </item> + + <tag><c>Free vars</c></tag> + <item> + is <c>NumFree</c> number of terms, each one encoded according + to its type. + </item> + </taglist> + </section> + + <section> + <marker id="EXPORT_EXT"/> + <title>EXPORT_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">N1</cell> + <cell align="center">N2</cell> + <cell align="center">N3</cell> + </row> + <row> + <cell align="center">113</cell> + <cell align="center">Module</cell> + <cell align="center">Function</cell> + <cell align="center">Arity</cell> + </row> + <tcaption></tcaption></table> + <p> + This term is the encoding for external funs: <c>fun M:F/A</c>. + </p> + <p> + <c>Module</c> and <c>Function</c> are atoms + (encoded using <seealso marker="#ATOM_EXT">ATOM_EXT</seealso>, + <seealso marker="#SMALL_ATOM_EXT">SMALL_ATOM_EXT</seealso> or + <seealso marker="#ATOM_CACHE_REF">ATOM_CACHE_REF</seealso>). + </p> + <p> + <c>Arity</c> is an integer encoded using + <seealso marker="#SMALL_INTEGER_EXT">SMALL_INTEGER_EXT</seealso>. + </p> + + </section> + + <section> + <marker id="BIT_BINARY_EXT"/> + <title>BIT_BINARY_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">4</cell> + <cell align="center">1</cell> + <cell align="center">Len</cell> + </row> + <row> + <cell align="center">77</cell> + <cell align="center">Len</cell> + <cell align="center">Bits</cell> + <cell align="center">Data</cell> + </row> + <tcaption></tcaption></table> + <p> + This term represents a bitstring whose length in bits is not a + multiple of 8 (created using the bit syntax in R12B and later). + The <c>Len</c> field is an unsigned 4 byte integer (big endian). + The <c>Bits</c> field is the number of bits that are used + in the last byte in the data field, + counting from the most significant bit towards the least + significant. + </p> + + + </section> + + <section> + <marker id="NEW_FLOAT_EXT"/> + <title>NEW_FLOAT_EXT</title> + + <table align="left"> + <row> + <cell align="center">1</cell> + <cell align="center">8</cell> + </row> + <row> + <cell align="center">70</cell> + <cell align="center">IEEE float</cell> + </row> + <tcaption></tcaption></table> + <p> + A float is stored as 8 bytes in big-endian IEEE format. + </p> + <p> + This term is used in minor version 1 of the external format. + </p> + </section> + + + </chapter> + + |