Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!ames!oliveb!amiga!cbmvax!jesup From: jesup@cbmvax.UUCP (Randell Jesup) Newsgroups: comp.sys.amiga.tech Subject: Re: Hunks & Segments & ... Message-ID: <6856@cbmvax.UUCP> Date: 12 May 89 18:17:13 GMT References: <232@mindlink.UUCP> Reply-To: jesup@cbmvax.UUCP (Randell Jesup) Organization: Commodore Technology, West Chester, PA Lines: 37 In article <232@mindlink.UUCP> a186@mindlink.UUCP (Harvey Taylor) writes: > Lots of the commands use the global vector. > 1) Is this structure defined anywhere? I do _not_ intend to use this info > for writing code, just to analyze my disassemblies. No. Nor will it be. Glad you're not thinking of using it, if you were we'd have to send out the Attack Gnomes. :-) > 3) Is there anything more to Segment Lists other than what is mentioned > in the AmigaDOS Tech Ref Man? > LONG Size of Segment > Prev BPTR ---> LONG BPTR to next segment [0 = eolist] > LONG Start of segment code/data > The reason I wonder is that there is a commonly used initialization > module [used in several commands] which references a pointer [Boffset?] > at the start of the segment code/data??? That's all there is. Some programs use their segments in funny ways that would make your brain hurt, like BCPL. Ignore it. > 5) What is the relation between Segments & hunks? Is there anything > hidden here? Normally, and code or data or bss hunk becomes a segment when loaded. > 6) In my disassemblies, I have noticed some peculiar (to put it mildly) > hunk structures such as Code & Data pieces of length 0; 20 or 30 > code & data hunks (many of them very short) in an 8K program. Is this > an artifact of inefficient &/ improper linking or is there a reason > behind it? Side effect of some compiler/linker setups. Blink does not produce 0 length hunks. Large numbers of hunks are due to large numbers of source files without use of the blink SMALLCODE/SMALLDATA options. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup