🚀 go-pugleaf

I am just adding DOSSEG support to ALINK, and I am a bit concerned
about the use of Rule 1 to place XAAA and DARK at the beginning of the
file, even though they are part of DGROUP. If someone has placed their
code segment into DGROUP, presumably it's for a reason, e.g. so that
all the code and data can be accessed with the same segment register,
which is then messed up if it is placed outside DGROUP because it is a
code segment.

I am inclined to treat XAAA and DARK under rule 3b.

Any comments?

Anthony

In article <7hnfm3$i3u$1@autumn.news.rcn.net>,
  bsmith@sudleyplacedespam.com wrote:
> Good question!  I traced through my linker (QLINK) to see why the
> segment order isn't what you think it should be and found an easily
> fixed bug which is also in MS Link (possibly for a different reason).
> Thanks for pointing it out.
>
> assassin17@rocketmail.com wrote:
> >
> >   bsmith@sudleyplacedespam.com wrote:
> > > assassin17@rocketmail.com wrote:
> > [snip]
> > > > 1. All segments with a class name ending in CODE
> > > > 2. Far data segments (segments outside DGROUP)
> > > > 3. Near data (DGROUP) segments, in the following order:
> > > >       a. Segments of class BEGDATA (reserved for Microsoft use)
> > > >       b. Any segments not of class BEGDATA, BSS, or STACK
> > > >       c. Segments of class BSS
> > > >       d. Segments of class STACK
> > > >
> > > > however, TLINK seems to always put segments with class 'STACK'
at
> > the
> > > > end, even if they're _not_ in DGROUP.  MASM's LINK behaves
according
> > to
> > > > the above list.  is there any standard to how other linkers
handle
> > > > DOSSEG, or can they arrange the different classed segments
however
> > they
> > > > want?
> > >
> > > The standard is the set of rules you mentioned above.  TLINK just
> > > doesn't observe them.
> >
> > thanks for the reply.  heh, i guess this explains why TLINK 7.1.30.1
> > just ignores DOSSEG..
> >
> > > > ----------
> > > > DOSSEG
> > > >
> > > > DGROUP GROUP OERP,AAAA,xaaa,LOPE,FBSS,DARK
> > > >
> > > > xaaa SEGMENT 'CODE'
> > > > xaaa ENDS
> > > >
> > > > CBF SEGMENT
> > > > CBF ENDS
> > > >
> > > > FBSS SEGMENT 'DATA'
> > > > FBSS ENDS
> > > >
> > > > LOSER SEGMENT 'STACK'
> > > > LOSER ENDS
> > > >
> > > > ztr SEGMENT 'DATA'
> > > > ztr ENDS
> > > >
> > > > aab SEGMENT 'BSS'
> > > > aab ENDS
> > > >
> > > > OERP SEGMENT 'BEGDATA'
> > > > OERP ENDS
> > > >
> > > > AAAA SEGMENT 'ARPA'
> > > > AAAA ENDS
> > > >
> > > > LOPE SEGMENT 'STACK'
> > > > LOPE ENDS
> > > >
> > > > ZZZU SEGMENT 'ARPA'
> > > > ZZZU ENDS
> > > >
> > > > DARK SEGMENT 'CODE'
> > > > DARK ENDS
> > > >
> > > > END
> > > > -----
> > [snipped a lot]
> > > According to the rules, the correct order (for the original
segments)
> > is
> > > as follows:
> > >
> > > Name  Class   Rule
> > > --------------------
> > > xaaa  CODE    1
> > > DARK  CODE    1
> > > CBF           2
> > > ztr   DATA    2
> > > LOSER STACK   2
> > > aab   BSS     2
> > > ZZZU  ARPA    2
> > > OERP  BEGDATA 3a
> > > FBSS  DATA    3b
> > > AAAA  ARPA    3b
> > > LOPE  STACK   3d
> > > _________________________________________
> >
> > ok, QLINK and M$ LINK both do it right then.  hmm.. why does ztr
end up
> > before LOSER, even thought it's after it in the source file?  is it
> > because FBSS is in the same class as ztr, and it's before LOSER in
the
> > code?
> _________________________________________
> Bob Smith -- bsmith@sudleyplacedespam.com
> a.k.a.       bsmith@qualitasdespam.com
>
> I've been getting a lot of junk e-mail lately,
> so to reply to me directly, delete "despam".
>

--
anthony_w@geocities.com
http://surf.to/anthony_w
http://www.geocities.com/SiliconValley/Network/4311/index.html


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---