muta...@gmail.com
2022-11-24 11:28:53 UTC
I think I don't need to switch to NE format or anything
else in order to support greater than 1 MB address
spaces.
MZ can stay the same, with an implied 4-bit shift, and
so long as a single object file doesn't cross a 64k
boundary within the executable, the OS can
compensate for the 4-bit implied shift and give an
effective 5-16 bit shift (using selectors or real shifts)
when it loads the executable.
But executables would be limited to 1 MB in size
while ever an implied 4-bit shift exists.
What I could instead do is here:
typedef struct {
unsigned char magic[2]; /* "MZ" or "ZM". */
unsigned short num_last_page_bytes;
unsigned short num_pages;
when the num_pages is 2048 or more, I shift to
an implied 8-bit shift (for the segment relocation
data).
Actually, it's not going to work, is it? I would need to
relocate offsets too, forcing a large memory size, or
I would need to get the code generator to have an
alignment of something higher than 16 bytes.
Otherwise, originally my plan was that an implied
8-bit shift would mean an executable could be
16 MB in size, which is hopefully big enough. Or
else a 9-bit shift would use up all the available
bits, ie a file size of 65536*512, 32 MB.
The biggest executable I have is an unoptimized
gcc which is a bit less than 5 MB, but that's only
32-bit at the moment.
Hang on a second - it will work. Even if code is 16
byte aligned, you can just use one segment selector
for the entire nearly 64k before padding to the
boundary and moving on to the next object file.
So if a.obj = 40k, b.obj=30k, c.obj = 30k, you would
have a.obj occupying the first 40k, 24k of padding,
then b.obj and c.obj would share the next 64k.
For a very minor change to the actual MZ format.
Zero change in fact, except for implied values.
Will it work or not?
If it works, would it be best to max it out with an
implied 9-bit shift? That's a fun number to have,
really, and it doesn't do any harm to anything.
BFN. Paul.
else in order to support greater than 1 MB address
spaces.
MZ can stay the same, with an implied 4-bit shift, and
so long as a single object file doesn't cross a 64k
boundary within the executable, the OS can
compensate for the 4-bit implied shift and give an
effective 5-16 bit shift (using selectors or real shifts)
when it loads the executable.
But executables would be limited to 1 MB in size
while ever an implied 4-bit shift exists.
What I could instead do is here:
typedef struct {
unsigned char magic[2]; /* "MZ" or "ZM". */
unsigned short num_last_page_bytes;
unsigned short num_pages;
when the num_pages is 2048 or more, I shift to
an implied 8-bit shift (for the segment relocation
data).
Actually, it's not going to work, is it? I would need to
relocate offsets too, forcing a large memory size, or
I would need to get the code generator to have an
alignment of something higher than 16 bytes.
Otherwise, originally my plan was that an implied
8-bit shift would mean an executable could be
16 MB in size, which is hopefully big enough. Or
else a 9-bit shift would use up all the available
bits, ie a file size of 65536*512, 32 MB.
The biggest executable I have is an unoptimized
gcc which is a bit less than 5 MB, but that's only
32-bit at the moment.
Hang on a second - it will work. Even if code is 16
byte aligned, you can just use one segment selector
for the entire nearly 64k before padding to the
boundary and moving on to the next object file.
So if a.obj = 40k, b.obj=30k, c.obj = 30k, you would
have a.obj occupying the first 40k, 24k of padding,
then b.obj and c.obj would share the next 64k.
For a very minor change to the actual MZ format.
Zero change in fact, except for implied values.
Will it work or not?
If it works, would it be best to max it out with an
implied 9-bit shift? That's a fun number to have,
really, and it doesn't do any harm to anything.
BFN. Paul.