🚀 go-pugleaf

First, thanks to Daniel Glasser for his posting.  There are one or
two things I want to clarify, though...

in article <2082@chinet.UUCP>, dag@chinet.UUCP (Daniel A. Glasser) says:
> 	... All relocatable references must be long and word-aligned. 

Clarification: all relocatable references must be longwords and must be
word-aligned.  (Another reading of the above sentence is, "They must be
longword-aligned and word-aligned.")

>     The BSS segment:
> 
> 	This is not stored in the file.  It is allocated at runtime
> 	by GEMDOS (actually, by the runtime startup.)

The BSS segment is allocated by GEMDOS.  If you ask for 32K of BSS, your
program will get 32K of BSS (as you can see by checking your basepage). 
What gets set up by the runtime startup is the HEAP, which is the space
between the end of your declared BSS and your initial stack pointer.  It
is the size of the HEAP that you set when you assemble GEMSTART (for
instance). 

>     The SYMBOL segment:
> 
> 	Type flags for the ds_type field:
> 
> 		DEFINED		0x8000		defined symbol
> 		EQUATED		0x4000		equated symbol
> 		GLOBAL		0x2000		global symbol
> 		EQUATED_REG	0x1000		equated register
> 		EXTERNAL_REF	0x0800		external reference
> 		DATA_RELOCATE	0x0400		data based relocatable
> 		TEXT_RELOCATE	0x0200		text based relocatable
> 		BSS_RELOCATE	0x0100		bss based relcatable

There are some more types than this: 0x0080 means "FILE" and is used by
the linker (well, by ALN, at least, and possibly LO68) to show where a
file starts.  (The symbol name is the file name, and the symbol value is
the address of the start of the text segment of that file (even if it
doesn't have anything in the text segment)). 

ALN also uses the next bit, 0x0040, to mean "ARCHIVE" -- this is an
ALN-specific extension, and is only used in conjunction with FILE.
The start of an archive is marked with a symbol of type ARCHIVE FILE,
where the symbol name is the archive name.  The end of the archive
is marked with a symbol of type ARCHIVE FILE with NO name (all nulls).

Thanks again to Dan Glasser for this posting.

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt