Author Topic: Target 64Tb of memory, not one less.  (Read 1160 times)


  • Hero Member
  • *****
  • Posts: 822
  • Karma: +3/-6
    • View Profile
Target 64Tb of memory, not one less.
« on: June 23, 2024, 10:57:19 am »
For the future and other follies
I have doubts, I read that the OS/2 could manage in Voice.
"In theory the 386 processor allows for 64 terabyte of virtual memory."

This is something that has been around my head for some time.
And it will not be that the maximum theoretical memory is always 4GB, but that it rotates in almost endless cycles, so that for example
You have 13GB = (4GBX3)+1GB available, it will show you 1GB, but that 1GB, if spent it appears as 4GB, are spent and ... re -empecing.
If this were so, it would be good to find that number that multiplies by 3 or whatever. Somehow I think I should
Another example, it can be like if you enter a building, on the ground floor you have 4gb,
 but if you go up to the first floor you have another 4gb = 8gb keep going up floors and imagine a skyscraper
  of 100 floors = 400gb

It could also be that the memory begins at the top of the building, and goes down the way,
 without the need for a floor number. Until it runs out.

If someone would tell you today, create a 64Tb memory, and you can only direct 4gb, how would you do it?

Could it be that we are only seeing the memory that is on one floor of the building?

To help understand the memory I use the freemem.exe program, the information it provides is not valid.
But it can help to understand what I say, and also the operation of the applications, how much memory they use,
When they use it, when an application is loading, when it is dead, etc ... in real time.
This program is freemem.exe very old, and I have seen it rotate many times.
And everything continues to work. By watching it rotate I mean having 100mb of memory and going through 4gb,
 and then 3.8g....

Could it be so?

What if we are putting memory limitations where they do not exist?
I mean: If you create a program and tell it to look at the memory and close it if it's insufficient,
why not let the system decide whether or not it's insufficient.
I leave you a screenshot, you can see used 2297mb, and simultaneously 2819mb free according to Vmem = 5116mb
Here I am using the memlinit in 4095, and because it won't let me put twice as much on it. Limits!!!!
All run nice.

** Ian has removed the attachment for the ebay listing **
« Last Edit: June 23, 2024, 01:14:53 pm by Ian B Manners »

Doug Clark

  • Sr. Member
  • ****
  • Posts: 318
  • Karma: +8/-1
    • View Profile
Re: Target 64Tb of memory, not one less.
« Reply #1 on: June 25, 2024, 07:56:00 am »

I think what you are describing is a segmented memory model - with each segment (floor in your description) being 4GB in size; memory addressed with pointer (register) to the segment  and a pointer (register) to the offset within the segment. 

To quote a Redbook
Like the 80286 processor, the 80386 processor also supports a segmented memory model, except that in the case of the 80386 the maximum segment size is 4GB. ... OS/2 version 2 implements the flat memory model by mapping the 4GB address space as a single code segment and a single data segment, each of which has a base address of zero and a size of 4GB.
End quote

So you can, theoretically, address much more than 4GB with a 32 bit processor and its 32 bit registers.  The advantage 64 bit processors have in addressing large memory is in not having to use segments and the performance hit that comes with switching segment registers, because their registers are 64 bits wide. 

But OS/2 is designed around a 32 bit flat memory model, meaning a single segment, and that single segment being a 4GB in size.


  • Hero Member
  • *****
  • Posts: 822
  • Karma: +3/-6
    • View Profile
Re: Target 64Tb of memory, not one less.
« Reply #2 on: June 27, 2024, 04:39:37 pm »

Thanks for the more technical explanation than mine - Ref. Redbook
But it would not hurt to verify it, in case the reality could be different.

But OS/2 is designed around a 32 bit flat memory model, meaning a single segment, and that single segment being a 4GB in size.
I have verified this line, and indeed it has to be 4gb, so it has to be changed the MEMLIMIT.exe to 4095,
so that the swapper works properly. Now I leave you with a config.sys setting that allows me to access
almost all the memory it recognizes the system when checking the BIOS, usually 3gb to 3.5gb approximately
depending on the equipment.
Everything is experimental, although I have applied it to my teams.

IFS=C:\OS2\JFS.IFS /CACHE:131072 /LW:32,128,8 /AUTOCHECK:*
SWAPPATH=C:\OS2\SYSTEM 2000 2048000

Don't forget to change the memlimit. Reboot.

In my case, forcing the system to exhaust all memory, when 2696 arrived, the computer crashed.
With Accessible to my system: 3 054 MB There are no prior warnings, except for this one.

You will see how many mistakes repair themselves.
If you want to run Dooble, I advise you to first open the Thunderbird or another application that eats up a
few megabytes of low memory. And is better to open a new window, that open a new tab.