Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!ames!lll-winken!uunet!glyph!nichiren
From: nichiren@glyph.UUCP (Andy Heffernan)
Newsgroups: comp.sys.amiga.tech
Subject: Re: ATOM
Summary: Who started this?
Message-ID: <196@glyph.UUCP>
Date: 9 May 89 05:29:15 GMT
References: <1158@psueea.UUCP>
Reply-To: nichiren@glyph.UUCP (Andy Heffernan)
Organization: Glyph UNIX, Kingston, NY
Lines: 24

In article <1158@psueea.UUCP> bartonr@psu-cs.cs.pdx.edu (Bob Barton) writes:
>
>  Whoops!  I should have looked at those load files a little more before
>posting that last message.  It seems that the sizes given in the hunk_header
>block do use the upper two bits for type information, even if the sizes in
>the individual hunks don't.  This apparently allows the loader to go ahead
>and allocate space for each hunk in the appropriate area of memory without
>having to first scan the file to look at the type of each hunk.

Hmmmm... I was talking about object files.

But load files have the type information on both places.

The addition of the bits to the hunk size information in hunk_header
is where that comment about "Old versions of the LOADER will interpret
the new hunk types as VERY large hunk[s] and not load [them]..,"
in the Bantam AmigaDOS manual comes from.  By "new hunk types"
they mean "hunk size words with high-order bits holding type information."
The actual hunk types still carry the information, though.

-- 
-------------------------------------------------------------------------
Andy Heffernan              uunet!glyph!nichiren            [1222 - 1282]
-------------------------------------------------------------------------