View Single Post
  #3152 (permalink)  
Old 04-24-2009, 11:47 AM
gguruusa's Avatar
gguruusa
Deep Thinker
Offline
Location: Mountain top
 
Join Date: Jan 2007
Posts: 3,252
Reputation: 4726
gguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributionsgguruusa should be added to the payroll for their contributions
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Re: WM 6.5 Kitchen QVGA and VGA Developer Edition

Quote:
Originally Posted by joojoobee666 View Post
I thought XIP memory was a pre-allocated region, meaning if the program/dll is a XIP it would be loaded into given a slot in XIP portion instead of the normal application space, thus giving me more usable RAM in the normal application space, therefore only losing out on XIP allocation space (which the application on question would never use). Is this incorrect?

This is based from this:
"When execute in place (XIP) DLLs are loaded, they are loaded from the top of the 64 MB space down. Each XIP DLL is based (positioned in the address space) when the ROM is created. When a non XIP DLL is loaded, it is positioned below the 32 MB boundary. Non-XIP DLLs, also called RAM-based DLLs, are those that are loaded from the object store, decompressed from ROM or loaded from an external file system such as a Compact Flash card. The upper 32 MB of the applications virtual memory space is only used for XIP DLLs."
You're switching from .exe to .dll now. .exe's are not handled the same as .dll. To some extent, you are confusing physical addressing w/ virtual memory map, as well.

Quote:
Originally Posted by vickylife007 View Post
Hmmm, almost having an headache reading all these technical stuff, but amazed at the same time how much am learning.
So final analysis of what you are saying sir, is we could just get skewed overly too excited moduling everything including what stays more beneficial in the overall interest as a file?
If you xip too many things, you'll fnd that your device locks up/crashes/inexplicably won't run things. Nothing comes for free.

Quote:
Originally Posted by vickylife007 View Post
Next complicated question will be how to know what to Module, and what is best left as a file? I have followed all the theories, but how do I just pick my oems and say "you are better of a module, and you a file"
Usage and size are the key factors. If it's used a lot, lean towards xip. If it's tiny, lean away from xip. Usage matters more than size.

Quote:
I have studied the SYS from 21159 till 21501 and found out that most SYS folders that were files in 21159 and 21169, were either partially or completely converted into modules form 2117+ and above. So does this not account for the speed of subsequent builds and improved memory management and efficiency?
Quote:
Originally Posted by joojoobee666 View Post
Well, I am no expert here, but one suspicion I have is that whoever dumped the sys could have done that. Also, quite a few modules often had to be converted into files in order for G'Reloc to work on the 6.5 builds, hence the change to WMReloc in PPCKitchen. Anyone is welcome to correct me on this.
Correct. The device(s) some builds were taken from do not have the quantity of RAM that newer devices have, so the choice to XIP or not is much more critical. As applications get greedier, this will apply to modern devices as well.
__________________
Grammar: The difference between knowing your shit and knowing you're shit.
Reply With Quote
This post has been thanked 1 times.