mlelstv@immd4.informatik.uni-erlangen.de (Michael van Elst ) (05/05/89)
nichiren@glyph.UUCP (Andy Heffernan) writes: >In article <239@medusa.informatik.uni-erlangen.de> mlelstv@immd4.informatik.uni-erlangen.de (Michael van Elst ) writes: > [with respect to special hunk flag bits] >>00 means default memory (MEMF_PUBLIC) > No, just 0. > ... That's right Andy. There is no need for MEMF_PUBLIC and it would break MEMF_PUBLIC rules if someone implements a protected AmigaDOS. 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. Michael van Elst E-mail: UUCP: ...uunet!unido!fauern!faui45!mlelstv
nichiren@glyph.UUCP (Andy Heffernan) (05/06/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. That's not what I see. A simple source file like: ---------------------------------------------------------------------- | int lonelyint; | ---------------------------------------------------------------------- When compiled with Lattice 5.02 using the -ab option (forcing bss data to be allocated from chip RAM) produces an object file that looks like: ---------------------------------------------------------------------- | 0000: 000003E7 00000002 74657374 2E630000 ...g....test.c.. | | 0010: 000003E9 00000000 000003F2 400003EB ...i.......r@..k | | 0020: 00000001 000003EF 01000003 5F6C6F6E .......o...._lon | | 0030: 656C7969 6E740000 00000000 00000000 elyint.......... | | 0040: 000003F2 ...r | ---------------------------------------------------------------------- Note the two long words at offset 0x1c. 400003EB hunk_bss_chip (hunk_bss with bit 30 set) 00000001 allocate 1 long word at load time Similar games can be played with code and initialized data hunks. > Michael van Elst > >E-mail: UUCP: ...uunet!unido!fauern!faui45!mlelstv -- ------------------------------------------------------------------------- Andy Heffernan uunet!glyph!nichiren [1222 - 1282] -------------------------------------------------------------------------