dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (05/02/89)
Out of curiosity I fooled around a bit with Atom to see where in
HUNKS object/executable format it set the bits. It sticks the bits in the
type field of the hunk. i.e. HUNK_HEADER and other types use up only the
lower word, leaving 16 flag bits free.
Of course, none of this is mentioned in the old tech ref (unless I
missed something).
Question 1: Are there any other special bits that are not mentioned?
Question 2: Apparently, some new hunks or symbol types were added
to the standard object module / executable format?
Can anybody tell me what they are?
1.4 requests
My request for 1.4 is to fix up LoadSeg(). The type field (i.e.
HUNK_this HUNK_that) has at least 16 free flag bits available inside object
files and executable files.
(1) A 'keep FH open bit'. This has nothing to do with overlays. I
want a bit that will keep the file handle used to load the
executable open, and an OS call to retrieve it. The segment
structure would be suitably modified to find a place for the
FH. Also, an OS call to close it (if not called, UnLoadSeg()
would close the descriptor).
The FH would be Seek'd to the beginning of the custom area before
LoadSeg() returns.
(2) LoadSeg() should not fail if data exists after the end of an
executable. (1) and (2) together allow for custom resources
or whatever other special items the programmer wants to implement.
(3) Implement the special form of LoadSeg() properly.. the one where
you can specify a file handle to LoadSeg() from instead of a
filename. This is currently used for overlays but is guruland.
(4) Add a new hunk type HUNK_STACK, that defines the size of a
stack segment. Add an OS call to retrieve the stack size
(returns 0 if HUNK_STACK did not exist). Apart from that, no
memory is allocated for the stack by LoadSeg().
(5) (optional): Add script file support ala #! in UNIX. If LoadSeg()
detects #! it will attempt to load the specified executable
placing the file handle for the script file as if the 'Leave FH
open' flag were set.
(6) Reserve some more bits in HUNK_HEADER's type word. Specifically,
reserve a bit to mean 'SHARABLE'. Reserve another bit to mean
'SHARE'. The SHARABLE bit simply means that the CODE hunk will
not be modified, the SHARE bit causes LoadSeg() to add a little
memory overhead and place the segment on a system list along with
the name of the program such that if another LoadSeg() call is
made for that program it will use the same CODE segment. Each
shared program has its own BSS and DATA segments, with the DATA
segments reloaded from disk or cached (your choice).
(7) reserve bits for future VM support... a 'this executable supports
the new memory management system' when you finally implement a
new memory management system.
(8) re-write LoadSeg() in C ... This is extremely simple to do, and
implement all of the above of course.
* If you don't want to do this, I would be happy to!
-Mattmlelstv@immd4.informatik.uni-erlangen.de (Michael van Elst ) (05/02/89)
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > Out of curiosity I fooled around a bit with Atom to see where in >HUNKS object/executable format it set the bits. It sticks the bits in the >type field of the hunk. i.e. HUNK_HEADER and other types use up only the >lower word, leaving 16 flag bits free. As I know (i.e. my AmigaDos Technical Manual), there are two bits that determine the memory type of a HUNK. They are the two MSB's in the size field of a hunk. Since hunk size is counted in term of long words these bits will never be used, even in 32bit address space. 00 means default memory (MEMF_PUBLIC) 01 means chip memory (MEMF_CHIP|MEMF_PUBLIC) 10 means fast memory (MEMF_FAST|MEMF_PUBLIC) 11 means another long word follows describing future attributes (not used) (Maybe you have to exchange the 01 with the 10 definition) Of course, the magics for hunk types fit in 16 bits but are defined as LONG. Michael van Elst E-mail: UUCP: ...uunet!unido!fauern!faui45!mlelstv
nichiren@glyph.UUCP (Andy Heffernan) (05/03/89)
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. >01 means chip memory (MEMF_CHIP|MEMF_PUBLIC) No, just MEMF_CHIP. >10 means fast memory (MEMF_FAST|MEMF_PUBLIC) No, just MEMF_FAST. >11 means another long word follows describing future attributes (not used) This response provided in case MEMF_PUBLIC ever becomes semantically meaningful in AllocMem() calls. $20 will go to Dave Haynie if his MMU-protected AmigaDOS predictions come to pass. You've got until December 31st, Dave. Here's the bill <crinkle, cruckle>. > >E-mail: UUCP: ...uunet!unido!fauern!faui45!mlelstv -- ------------------------------------------------------------------------- Andy Heffernan uunet!glyph!nichiren [1222 - 1282] -------------------------------------------------------------------------
nichiren@glyph.UUCP (Andy Heffernan) (05/04/89)
In article <190@glyph.UUCP> nichiren@glyph.UUCP (Andy Heffernan) blithers: [...] >$20 will go to Dave Haynie if his MMU-protected AmigaDOS predictions >come to pass. You've got until December 31st, Dave. Yeeps! I mis-remembered Dave's original prediction. He's talking virtual memory; I'm just foaming at the mouth. >Here's the bill <crinkle, cruckle>. I'll still make good on the offer, though. -- ------------------------------------------------------------------------- Andy Heffernan uunet!glyph!nichiren [1222 - 1282] -------------------------------------------------------------------------