So, I was thinking about virtual machines, specifically about extending a 32 bit virtual machine to have access to more memory by segmenting the memory. Now, the 8086 supported 1 MB with a segment selector offset four bits, so each segment differed from the one preceding it by 16 bytes. I was thinking about having the segment selector offset 16 bits, supporting a 48 bit memory space and making adjacent segments differ by 64 KB, or I could offset it 24 bits and have a 56 bit memory space, with segments differing by 16 MB. Which is more useful, larger or smaller segment differences? Should I just make each segment distinct, allowing a 64 bit memory space?
Name:
Anonymous2009-09-27 19:19
AH YES THE GOOD OLD DARK AGE OF MEMORY SEGMENTATION. LETS GO BACK TO THAT>
Name:
Anonymous2009-09-27 19:35
I want to build a virtual machine in a virtual machine.
Name:
Anonymous2009-09-27 21:11
>>2
they still use segmentation today, bro.
they still use paging too ( ´・__・)
Name:
Anonymous2009-09-27 21:26
It's already possible for a 32-bit machine to access for than 4GB using PAE (you're then stuck at 64GB, though). On windows there's also Address Windowing Extensions, which allows a 32-bit program to access more than the usual 2GB of user-space memory.
Name:
Anonymous2009-09-27 22:13
Suggested segment layout for Virtual Machine:
Segment 1: List cells
Segment 2: Fixnums
Segment 3: Flonums
Segment 4: Bignums
Segment 5: Symbols
Segment 6: Arrays
Segment 7: Value cells for symbols
Segment 8: Number stack
>>5
Nearly 4 years later, the average desktop still has far below 64GB of RAM. PAE is standard on anything above XP RTM (needed for DEP), but thanks to MS deliberately limiting 32-bit Windows to 4GB (easily patched out) and spreading huge amounts of FUD about that, we've now got bloatier-than-ever 64-bit software on systems that don't need it at all, and a horrible non-backwards-compatible 64-bit architecture to go along with it.
Name:
Sagist2013-05-09 16:41
I'd just like to bump all the actual /prog/ threads.
>>10
PAE is a disgusting hack. The kernel has to constantly juggle its page mappings to keep everything sane, and you still can't access more than 4GB per process.
You can always choose to run 32 bit programs on a 64 bit kernel if you're concerned about the pointer bloat.
Your VM should have multiple segments, of which only Segment 0 is reachable during normal operation of your VM. Here is the full list of segments:
Segment 0: Flonums with exponent 0 to 99.
Segment 1: EGGOGs, flonums with exponent 100 to 199, can be used in calculations, but cannot be displayed.
Segment 2: ZGGOGs, flonums with exponent 200 to 399, can be used in calculations, but cannot be displayed.
Segment 3: Untameable beasts which can modify the instruction memory of your VM seemingly at random or crash it.
Segment 4: OC-lycanthropes which copy the structure of other segments in warped form, can be used to study other segments.
Segment 5: Darkness. Any attempt to access or modify data in this segment your VM should clear its screen, wipe its registers and memory banks, and halt.
Segment 6: C-EGGOG-lycanthropes which mutate your counter register.
Segment 7: Longmonsters mirror other segments in slightly warped form, can be used for analysis.
Segment 8: Zeroes. Anything written to this segment is immediately turned into a zero.
Segment 9: Flonums with negative exporent -99 to -1.
Name:
Anonymous2013-05-11 6:46
If you want to create a viral machine, just clone a jew. Jew is viral, and all jews are golems (machines animated by dark magic).
>>13
Interesting how "disgusting hack" is the EXACT SAME PHRASEOLOGY used by MS' FUD-spreading shills... meanwhile they ignore the fact that PAE is required for DEP! All Windows OSs since NT4 supported PAE so they all had a hard physical RAM limit of 64GB, but the idiots at MS decided to limit it lower.
The majority of processes don't need anywhere near 4GB. The way 64-bit is implemented is completely backwards-incompatible. You can't use 64-bit registers or instructions in 32/16-bit mode like you can with 32-bit in 16-bit. Using 64-bit addresses on a system that has at most 34 or maybe 35 bits of physical address space is a HUGE waste.
Full-64-bit is for HPC grids and big data stuff like that. Not the average desktop.
>>16
Yes, average researchers use average desktops. I am an average researcher, I do use an average desktop, and I still have processes requiring way more than 4GB of memory.
Name:
Anonymous2013-05-11 22:02
>>16
I like my time_t to be a single primitive, thank you very much.
Name:
Anonymous2013-05-11 22:08
>>15
Hi there, Nikita. I think I found a good identification criteria for you.
>>17
You're not an average user and should go ask for a cluster or something to use instead.
>>18
Blame the UNIX guys for that. The monotonic timestamp (FILETIME) has been 64-bit on Windows NT for a long time.
Name:
Anonymous2013-05-12 15:40
>>20
A cluster doesn't help with processes that have large memory requirements. I used to work in a research lab and it wasn't exactly an uncommon problem.
>>23,24
Large graphs. Do not worry, I will try your cluster next.
Name:
Anonymous2013-05-13 22:42
>>23
It was a simple Beowulf cluster for running lots of small parallel jobs, not a fancy NUMA system. Worked well for most processing, but then there's always that one researcher who has to try out the new processing method written by some grad student, who's never even taken a CS class, that chews up RAM like it's going out of style.