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