Path: utzoo!attcan!uunet!lll-winken!xanth!ukma!gatech!mcnc!rti!sas!toebes
From: toebes@sas.UUCP (John Toebes)
Newsgroups: comp.sys.amiga.tech
Subject: Re: New AmigaDOS hunk types
Message-ID: <1054@sas.UUCP>
Date: 25 May 89 12:45:10 GMT
References: <8905162220.AA21138@postgres.Berkeley.EDU>
Reply-To: toebes@sas.UUCP (John Toebes)
Organization: SAS Institute Inc, Cary NC
Lines: 54

In article <8905162220.AA21138@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
>	New hunk types.
>
>	Chris isn't the only one who wants to know!  post replies to the net!
>
>	* what additions has Lattice made     ?
>	* are they to be considered 'standard'?
I will get together the document on the new types and see about posting it.
It is however quite long so perhaps it might be better sent to
comp.amiga.sources.  To quickly summarize the extensions:
  a.  3 new hunk types to support data relative references.
        1015 -  DREL32
        1016 -  DREL16
        1017 -  DREL8

  b.  3 new reference types to sypport data relative references.
        133  - DEXT32
        134  - DEXT16
        135  - DEXT8

  c.  New hunk names to control merging of data
        NTRYHUNK - for the overlay manager to make it first
        __MERGED - The special data relative hunk
        _NOMERGE - A hunk not to be merged with anything else

  d.  New naming conventions to support coalescing of constructor/
      destructor functions for languages like C++ and Modula-2
       A table of pointers to functions is built.  I don't have
       the naming conventions on hand.

  e.  Extensions to support library indexing:
       1018 - HUNK_LIB
       1019 - HUNK_INDEX
      Designed to allow indexing of the libraries while at the same time
      retaining the ability to construct libraries the old way by
      just concatenating the object modules together.

All of the object file format extensions were reviewed and approved by
Commodore before they were implemented - in particular the library
indexing went through some careful scruitinizing.  It has been acknowledged
that these extensions are indeed part of the standard object file format.

One additional *CONVENTION* that BLINK established is that HUNK_DEBUG
must have one longword at the start of the hunk that is updated by BLINK
to indicate the offset of the coalesced hunk that it is associated with.
If you are generating one, it is best just to store a 0 as the first longword.

Additionally, Lattice has defined a debug file format.  The information
can be obtained by contacting Lattice directly.

/*---------------------All standard Disclaimers apply---------------------*/
/*----Working for but not officially representing SAS or Lattice Inc.-----*/
/*----John A. Toebes, VIII             usenet:...!mcnc!rti!sas!toebes-----*/
/*------------------------------------------------------------------------*/