Som Object File

Som v1.7

Format

start end
code* (in hex)
start end
data* (in decimal)
num  (number of entries of symbol table)
symbol table*

each symbol table entry is : name type ref arg arg2

What is stored in the object file?

The object file stored code, data and exported symbol table.  The code (T-code instructions) is in hex (for fast load as it is 32-bit). The data is in decimal.  The data is the snapshot of memory when finished compiling and executing the immediate lines. The amount of data is dictated by the amount that has been dynamically allocated when compile the program. The symbol table is important for initialised the global variables. This is a change from previous version which relied on the code generator to generate a "replay" of the immediate line so it is not necessary to store the data in the object file as it can be recreated.  However, having snapshot is useful in many situation, such as the static array which is introduced in this release.

Consider the symbol table.  What information must be recorded to allow CS, DS to be relocatable?  For CS, start address, there is only one kind of object, code.  For DS, there are several kind of objects: global variables, constant static array etc.  As the snapshot is a contiguous block, it can be relocated as a whole.  However, if a variable contains a pointer to DS, it must be noted so that its value can be relocated.  The pointers are:

1) base-address of static array.  A static array is an array that is allocated at compile-time, hence its  base-address is known at compile-time.  This happens when define an array by an immediate line (outside function definition), such as

  a = array 10
  b = array {11 22 33}

2) a pointer to static string.  A static string is a string created at compile-time such as a string embedded in the source code or a string created by an immediate line that its value is assigned to a global variable, such as

  to warn = { prstr "warning message" }
  s = "this is a string"

Aliasing of variables will not be analyse hence they will not be relocated.  Care must be taken in using such variables because interactive-mode and run-only-mode may behave differently when DS is relocated.

to denote the kind of global variable: scalar, static array, string pointer; the field "Arg" in the symbol table is used:
0  scalar
1  static array
2  string pointer

This information will be used in the loader to relocate DS.

7 Nov 2005

som v.2.4

The object file is the same format as som-v2 except:
1)  magic cookie is 5678916  (som16 object)
2)  it includes symbol table with the form: (name type ref arity lv)

Format

magic      (5678916  for som v24)
start end  (code segment)

code*
start end   (data segment)
data*
num  (number of entries of symbol table)
symbol table*

each symbol table entry is : name type ref arg arg2

You can read the detail of static array type in  som object file v 1.7

som v3.1

magic                            5678931
start end (op arg)*              code segment
start end data*                  data segment
size  (name type ref arity lv)*  symbol table

som v4.0, 4.1, 4.2

similar to v3.1 except magic is 5678940,  5678941, 5678941 (yes 4.2 use 5678941)

som v5.0

A little change in the instruction format in the code segment (to make it easy to locate individual instruction).  Link vectors make loading object file faster because of not scanning the symbol table.  Link vectors are special locations, in v5.0 there are:  addresses "loadfile" and "CS". If there is no link vectors (size = 0) the loader will scan the symbol table for the required information.  This link vectors are not produced by the compiler, they are manually edit into the object file because the compiler is not specific to any source, hence it does not know about link vectors of a particular program.

magic                                5678950
start end (ads op arg1 arg2 arg3)*   code segment
start end data*                      data segment
size (vector)*                       link vectors
size (name type ref arity lv)*       symbol table

 5 Dec 2009