Walter Bright <boost@digitalmars.com> writes:

quoted text
> On my project, one. But I've seen this problem repeatedly in other
> projects that had multiple developers. For example, I used to use
> version 1 of an assembler. It was itself written entirely in
> assembler. It ran *incredibly* slowly on large asm files. But it was
> written in assembler, which is very fast, so how could that be?
>
> Turns out, the symbol table used internally was a linear one. A
> linear symbol table is easy to implement, but doesn't scale well at
> all.

Well, my first system was a Z80 computer with an editor/assembler in
ROM (4kb).  At one time I tried figuring out the size requirements of
symbols.  It was two bytes for each symbol.  Namely the value.  The
"symbol table" was located behind the source code.  Whenever this
marvel of technology encountered a label, it searched the source code
from the beginning for the definition of the label, keeping count of
all label definitions in between.  When it found the definition, the
count corresponded to the position in the symbol table.

So compilation times were O(ns), with n the number of symbol uses and
s the size of the source code.

Implementing in a higher language would not have helped: memory
efficiency was what dictated this layout.  Given that the whole
available memory was perhaps 50kB, assembly language modules could not
get so large that scale issues were deadly.  But the assembly times
did get annoying sometimes.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html