ian@sibyl.eleceng.ua.oz.au (05/08/90)
Well, I have just been trying to compile Bruce's monitor using gcc/gas/gld. Not too bad. I have written a sed script to convert between Bruce's assembler syntax and gas. This is not too hard because the addressing modes syntax is the same. 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? 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? Bruce uses a -D option for your linker. The GNU ld also takes a -D option but I suspect the semantics are different. The GNU loader used -Tdata to specify the starting address of the data section and -D specifies the *size* of the data section. I *think* -Tdata is the one to use. 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.
culberts@hplwbc.hpl.hp.com (Bruce Culbertson) (05/09/90)
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
ian@sibyl.eleceng.ua.oz.au (05/09/90)
Bruce Culbertson writes: > [ lots of good stuff about where things go in the monitor ... ] > > Now are really confused? > Argh, no I think that makes things much clearer. I might have some problems with my (port of) the gnu linker rounding things differently to your ROUNDUP. I'll have to check. Ian