a218@mindlink.UUCP (Charlie Gibbs) (05/07/89)
In article <247@medusa.informatik.uni-erlangen.de> mlelstv@immd4.informatik.uni-erlangen.de (Michael van Elst ) writes: >... >The only thing that I want to point on is, that memory type information >isn't placed in the hunk type fields BUT in the hunk size field. It's reassuring to see that I'm not the only one who was taken in by this. In the AmigaDOS Technical Reference Manual (part of Bantam's AmigaDOS Manual), first edition, page 283, under the heading "How the Bits Work", the bits are indeed described as being part of the hunk length field. However, near the top of the same page, under point 3, the following information can be found: "The linker will now take nine (9) hunk types instead of 3. The old types were hunk_code, hunk_data, and hunk_bss. The new ones will be: hunk_code_chip = hunk_code + bit 30 set hunk_code_fast = hunk_code + bit 31 set hunk_data_chip = hunk_data + bit 30 set hunk_data_fast = hunk_data + bit 31 set hunk_bss_chip = hunk_bss + bit 30 set hunk_bss_fast = hunk_bss + bit 31 set The linker will pass all hunk types through to the LOADER (coagulating if necessary). The LOADER uses the hunk header information when loading." I set up an expermient to test this. First I created a small object module (using A68k) containing code, data, and BSS hunks, with no MEMF_CHIP or MEMF_FAST flags set. Then, using NewZap, I set flags in various places in the module, and tried passing the result through both Alink and Blink. When I set the bits in the hunk length field (as suggested under the "How the Bits Work" heading in the manual), Blink stripped the bits from the file and ignored them completely. Alink said "insufficient store during pass2" and aborted. When I set the bits in the hunk type field (as suggested under point 3 in the manual), both Alink and Blink processed the module. The bits were passed through to the corresponding hunk type fields in the linker output. The bits were also set in the corresponding hunk lengths in the hunk_header table. This is probably where the confusion arises. Conclusion: The MEMF_CHIP and MEMF_FAST bits are set in the hunk type field in object modules. In load modules, MEMF_CHIP and MEMF_FAST are set both in the hunk type fields and the hunk length fields in the hunk_header table. Under no circumstances are MEMF_CHIP and MEMF_FAST set in the length field at the beginning of a hunk itself. Charlie_Gibbs@mindlink.UUCP "The terms 'undefined' and 'unspecified' have been given definitions." -- revision to the IEEE 1003.1 POSIX Standard