Compiling with /LARGEADDRESSAWARE

[orb]

Is running down a character array with a signed integer and then calculating character positions by means of adding a negative value to the array pointer a problem?

I don't see a problem there - 'i' isn't a pointer but offset. LAA doesn't change how offsets are added to displacements. You aren't calculating a size of the region by subtracting pointers, which in LAA may give a result bigger than the maximum of a signed int (so signed ints can't be used for lengths or sizes with LAA).

Some functions which normally returned negative value on an error instead of an address (pointer) may cause a problem.

 

[Face]

I don't see a problem there - 'i' isn't a pointer but offset. LAA doesn't change how offsets are added to displacements. You aren't calculating a size of the region by subtracting pointers, which in LAA may give a result bigger than the maximum of a signed int (so signed ints can't be used for lengths or sizes with LAA).

Some functions which normally returned negative value on an error instead of an address (pointer) may cause a problem.

So if I understand that right, for most addons, this should be just an academic problem, no real one. Or is there a real world example of an addon that does that kind of thing?

 

[Xyon]

This is all getting a bit OS-Warsy. Can we stick to the point?

 

[martins]

So that means with this flag we can use up to 4GB on 64-bit OS, and up to around 3GB on 32-bit OS, right? That is also without too much incompatibility with old addons, isn't it?

Sounds like a win.

As for the pointer arithmetics: what would be a real-world example of code to violate that rule?
Is running down a character array with a signed integer and then calculating character positions by means of adding a negative value to the array pointer a problem? I.e. having something like this:

int i=-1;
char a[5]="Test";
char b=*(&a[1]+i);
if (b!='T') fail();

Could that fail with LAA?

As I understand it, the danger with the 4GB address space is to store any address differences in an integer-sized variable, since such differences can theoretically range from -4GB to +4GB, which would need 33bits to represent.

Take this contrived example:

char *a = new char[3GB];
char *a0 = a;
char *a1 = a+3GB;
int da = a1-a0;  // Problem!
for (int i = 0; i < da; i++)
  *(a0+i) = 0;

The above could be fixed by replacing int with unsigned int, but then you could come up with an even more contrived example where that wouldn't work either:

char *a = new char[3GB];
char *a0 = a;
char *a1 = a+3GB;
UINT da = a0-a1; // Problem!
for (UINT i = -1; i >= da; i--)
  *(a1+i) = 0;

So you have to store pointers in unsigned variables and you have to be careful not to store negative differences.

 

[Face]

As I understand it, the danger with the 4GB address space is to store any address differences in an integer-sized variable, since such differences can theoretically range from -4GB to +4GB, which would need 33bits to represent.

Take this contrived example:

char *a = new char[3GB];
char *a0 = a;
char *a1 = a+3GB;
int da = a1-a0;  // Problem!
for (int i = 0; i < da; i++)
  *(a0+i) = 0;

The above could be fixed by replacing int with unsigned int, but then you could come up with an even more contrived example where that wouldn't work either:

char *a = new char[3GB];
char *a0 = a;
char *a1 = a+3GB;
UINT da = a0-a1; // Problem!
for (UINT i = -1; i >= da; i--)
  *(a1+i) = 0;

So you have to store pointers in unsigned variables and you have to be careful not to store negative differences.

I see. However, what addon really has the demand for such code, especially with allocated memory sizes above 2GB?

As I understand it now, it only really hurts if you've got deep into managing large memory chunks. Orbiter itself certainly falls in that category, but add-ons? I'm all for trying it out and see what really fails.

 

[dbeachy1]

Yes, it does. It does not, however, spell out how *64-bit Windows* works with 32-bit programs.

Good point, I missed that -- I stand corrected. A 32-bit app on 64-bit Windows can indeed access a full 4 GB of RAM (I read it here as well).

My apologies, all, for posting incorrect info on this. It just goes to show how it's good to have a community of developers to make sure the info is right.

 

[martins]

If I may make a suggestion, if you replace the micro-elevations of the forests with say, tree models, that could reduce the resolution needed for the terrain and you would only need to store the position of each instance and let the graphics card do the rest. Perhaps you could also use terrain polygons and a tile-able texture place on those polygons (with blending where needed) similar to what (I think) FSX does. These two things combined should significantly reduce memory usage by the core and give more memory to the addons.

The recent increase in the mesh resolution of surface sphere patches wasn't really done in order to implement these "micro-elevation foliages"; that was just a nice side effect. The main reason was to reduce the discrepancy between mesh resolution and texture resolution. The texture resolution for each patch is 512x512 pixels, while up to now the mesh resolution was 33x33. This mesh resolution is a heritage from when planets were smooth spheres, where you didn't need much resolution. However now, with elevation support, for a given surface LOD level matched to the texture resolution, the elevation resolution is visibly too low for rough terrain (see here: http://orbiter-forum.com/showthread.php?p=524220&postcount=21, so the adjustment from 512/33 to 512/65 or 512/129 was just a means of redressing this discrepancy.