Replace MethodIDs with ImageIDs #326
Conversation
* Drop unused regions * Expand most regions to 32M, with exception of stack/data at 16M * Use full 2^28 address range available
This is an initial milestone for supporting upcoming continuations.
| input : ORIGIN = 0x04000000, LENGTH = 32M | ||
| stack : ORIGIN = 0x02000000, LENGTH = 16M | ||
| data (RW) : ORIGIN = 0x03000000, LENGTH = 16M | ||
| heap : ORIGIN = 0x04000000, LENGTH = 32M | ||
| prog (X) : ORIGIN = 0x06000000, LENGTH = 32M |
There was a problem hiding this comment.
Is there a reason not to put prog @ 0x08... - 0x0c...? I was of the impression that system memory starts only after 0x0c and that nondet was now below @0x02. It seems like 64M for heap and 64M for code would be better than 32M for heap and 96M for program. Or maybe even more room for heap.
There was a problem hiding this comment.
That all makes great sense. I was also thinking maybe prog should live above the system region? Like maybe reading from the PC could use a special memory op.
| pub const STACK: Region = Region::new(0x0200_0000, mb(16)); | ||
| pub const DATA: Region = Region::new(0x0300_0000, mb(16)); | ||
| pub const HEAP: Region = Region::new(0x0400_0000, mb(32)); | ||
| pub const TEXT: Region = Region::new(0x0600_0000, mb(32)); | ||
| pub const OUTPUT: Region = Region::new(0x0800_0000, mb(32)); |
There was a problem hiding this comment.
Is there any reason to have a specific output + commit region anymore? As far as I can tell there is no reason output can't just send heap pointers to the host. Also for the commits, cant we just have a single SHA256 state and a single 16 word staging buffer (both in the heap), and just write words to the staging buffer and kick off a compress whenever it's full?
There was a problem hiding this comment.
Ah yes, that's a good point on both counts. Now that we have sys_sha_buffer, we can probably drop the COMMIT region. I also don't think we need an OUTPUT region anymore!
|
|
||
| let elf_sha = Sha256::new() | ||
| // Method ID calculation is slow, so only recalculate it if we | ||
| // actually get a different ELF file. |
There was a problem hiding this comment.
Am I correct to assume that imageId calculation is much more efficient so we no longer need to cache it or should we still consider caching the imageID to avoid recalculating?
There was a problem hiding this comment.
It seems to be pretty fast without having to cache it. Caching comes with all sorts of complexity and potential for bugs. If we find out it's still too slow we can bring caching back.
No description provided.