was this caused by somebody who said, 32bit should be enough for anyone? ;-) regards, Michael At 15:57 07.09.2001 +0200, you wrote: >Grrrr, Opera crashed on me when I composed the reply... >What was I saying... >Oh yes: >The biggest problem IMO is not the vm structures overflowing, but the fact= =20 >that >_all_ the physical memory is mapped into a portion of the virtual space of= =20 >each >team (in the kernel part, which is limited to 2G). >This trick is used in BeOs (and also in AtheOS) to ease writing some kernel >routines. >So what do you think will happen if you have 4G of RAM ??? >it will just try to map your 4G to the 2G space it is allowed to use... > >Must-reads: >http://www.benews.com/story/3995 Kurt Skauen interview on BeNews telling=20 >about >the 2GB problem > >another which describes the virtual space organisation but I can't get >my hands on this one, > >http://www-classic.be.com/aboutbe/benewsletter/volume_II/Issue25.html >quite old, about virtual/phys spaces > >http://www-classic.be.com/aboutbe/benewsletter/article_index.html >An @ I advise you to bookmark as it has a lot of infos :) > >See you, >Fran=E7ois. > >En r=E9ponse =E0 Marcus Overhagen <dos4gw@xxxxxx>: > > > > > On Thu, 06 Sep 2001 06:00:21 PM, "p willis" <p.willis@xxxxxxxxx> > > wrote: > > > > >It's pretty easy to make a flat 32 bit memory model that accesses the > > full 4 > > >gigs *plus* with some additional virtual paging code the model can be > > extended to > > >super-pages or 4 gig blocks (or parts of blocks) swapped from the HD. > > > > I'm not sure if you understand the concept of virtual memory, and the > > problem. > > Each application has it's own 4GB virtual address space, and into this > > virtual space > > physical memory is mapped in (or harddisk memory, paged in/out), while > > Be decided > > to use some space in the virtual adresses of each process for the > > kernel. > > > > The problem seems to be that the current BeOS kernel's internal data > > structures are not > > large enough to support more than 1 GB physical memory currently. > > > > > > >Just make sure to use 64 bit counters in all your structs so that when > > BeOS > > >requires porting to wider architecture the underlying framework can > > support > > >the move. > > No, don't do this. continue to use normal pointers. > > While a void * is now 32 bit, it will be 64 bit then. > > > > But please stop casting a pointer into an int, or worse, into an > > int32. > > This would break your program one pointers get 64 bits wide. > > > > > > regards > > Marcus > > > >