Re: code directive question

Ben Dugan writes:
 > 
 > Thanks for these links, Craig.  I've seen them both, but did not find 
 > what I was looking for (how to refer in an asm file to a section by the 
 > name it has in the linker script).  But now I'll go back and read them 
 > more carefully.

	You do realize, don't you, that you get to modify the linker
scripts to re-carve-up the address space to include additional segments
by whatever name (for use in the code directive) that you like?

	It works, though it's not as flexible as I would like.  For
example, I like to place my usually small, assembler coded, interrupt
handlers at location 4 (14 bit parts), rather than using a goto (I'm
not always that tight on cycles, but it has become a habit).  It's
easy enough to make a 3 word segment for the reset "vector", and
another larger section for the interrupt handler, followed by other
stuff.  Sadly, to avoid wasting space in the first 256 words (usually
all of my dispatch tables will fit there, so I don't have to fiddle
wiht PCLATH on 4k word and smaller parts), I need to tie the size of
the interrupt handler section (and the start of the rest of the frist
256) to the actual size of the interrupt handler.  I could automate
this with, say, a python script to extract the size of the interrupt
handler from, say, the listing file of the assembly of the module
containing the interrupt handler, and jogger my makefile to run the
script whenever that listing is newer than the linker script.  But I
don't see a way to do it within the assembler-linker tool chain.

	Similarly, in those cases in which total code space is tight,
I'd prefer not to waste any portion of the first 256 words not used
by dispatch tables.  I'd like code that doesn't care where it goes to
fill in the remainder of the first 256 words, and be willing to cross
the 256 word boundary without having to have the boundray separate
segments from separate source files.  Again, I could do this with a
linker script generating tool, but the scripts themselves don't seem
powerful enough themselves.

	What might work (as a pie in the sky linker enhancement) would
be to allow nested segments.  In my case: a segment beginning at 4,
and running through the rest of what part of page 0 is implemented on
the device (the unnamed code segments put code here; Inside that, a
segment from 4 through 255, let's call it paragraph 0, where my
dispatch tables go; Inside that, a segment from 4 through 255 called
interrupt handler.  Then you have the linker place all the code for an
inner segment before placing code for the containing segments.  My
interrupt handler would be place first, and would begin at location 4,
as required.  Then there would be no more sections for the interrupt
handler segemnt, so the linker would be free to place sections
designated for paragraph 0, with the actualy usage within the
contained interrupt handler segment excluded.  One would hope to get
an error if there wasn't enough space in the designated segment for
all the code specified to go there.  When all paragraph 0 segments
were placed, the linker, begining with whatever's left of paragraph 0,
would place the rest of the anonymous segment code.  Just musing.

	As long as I'm venting, I'm disappointed that I can't have
more than one segment in a given ASM file with the same segment name.
My sample usage is that you're coding along and come to a place where
you need a dispatch table.  It makes software engineering sense to
describe the dispatch table right there, rather than collected with
others somewhere else.  So you switch from the anonymous segment to
the paragraph 0 segment (see above), code your table, and then want to
switch back to the anonymous segment for the implementations of the
places dispatched to.  But no, you would then have two sections in one
file going to the ".code" section.  Still worse if you're coding along
and come to a second place for a dispatch table in the same file,
since you would then have two sections for the paragraph 0 segment.
(Actually, I suspect that this is a limitation of coff, and is thus
harder to fix than it sounds.)

							Bill