🚀 go-pugleaf

Ian writes:

> I have a couple of questions about the semantics of the pseudo-ops
> though. What does ".program" and ".static" do? I have assumed they are
> the same as ".text" and ".data" is that right?

Exactly right.  Actually, my assembler accepts any of those.  .Program
and .static are what National used in their NSX assembler for the 32000.

> Gnu ld does not define _bdata. I am currently linking in a little
> assembler first.s which defines _bdata to be the pc for the bottom of
> the .data section. Does that sound right?

	_btext = beginning of the text segment
	_etext = end of the text segment
	_bdata = beginning of the data segment
	_edata = end of the data segment = beginning of the bss segment
	_end   = end of the bss segment

Note that BSS is always placed after the data segment by my linker.
The -T option my be used to place the text segment anywhere.  By
default, _btext = 0 but if you use -T <num>, then _btext = <num>.
The -D option my be used to place the data segment anywhere.  By
default, _etext = _bdata but if you use -D <num>, then _bdata = <num>.

My linker rounds _etext up to a page boundary, a feature I may change
since you then do not know where the last instruction is.  You can
always round up _etext if that's what you want.  However, I will
always round up _bdata so ROUND_UP_PAGE (_etext) will always be _bdata
if you do not use -D.

> One thing I don't understand is what use a .data section is in the
> context of a rom monitor. RAM will be uninitialized and ROM is
> unalterable. Constant data can be put in the .text segment (and end up
> in ROM) and any non constant data will have to be initialized and
> might as well be in the .bss segment.

The compiler assumes a program environment with text, data, and bss
segments.  You do not want to change the compiler just to compile a
ROM.  Also, you do not want to try to remember that you must not use
initialized data because you'll probably forget.  So, the solution
I came up with is to make the text/data/bss model a reality before
the monitor tries to use anything in its data segment.

The monitor knows that the data segment is placed in the a.out file
starting at the next disk block after the end of the text segment.
The text segment and the data segment are copied, without changing
their relative positions, from the a.out file to the ROM.  Hence,
the following code copies the data segment from the ROM into RAM
where the program expects it.  It assumes that you ran the linker with
the option -D <address> where <address> is in RAM.

	{
	  char *s, *d;
	  extern char _etext[], _bdata[], _edata[];

	  for (s = ROUND_UP_BLOCK (_etext), d = _bdata; d < _edata;)
	    *d++ = *s++;
	}

It is also a good idea to zero the bss segment.  Use this code:

	{
	  char *d;
	  extern char _edata[], _end[];

	  for (d = _edata; d < _end;)
	    *d++ = 0;
	}

I lied about one thing above.  The data segment is currently page
(not block) aligned in the a.out file.  I never noticed this mistake
because on the 32016 both the page size and block size were 1K.
I'll fix this soon and post a cdiff for the linker.

Now are really confused?

Bruce Culbertson