A quick question about addresses...

[cdbc]

Hi
What would be the lowest possible valid pointer address in a freepascal program, expressed as a PtrUInt?!?
i.e.: start of address space...
edit: 64bit ...and Linux if that matters...
Regards Benny

[Thaddy]

nil starts at, well,  zero and is  a valid pointer. Otherwise it is the start address of the heap memory. Nil is an address, not a constant!
I guess you mean the latter? A more complicated answer is also possible: there is a difference between executable memory and store memory on most platforms and there is a stack.., but in effect the first two.
In C it is (void *)0, in fpc it is nil. That is in practice, because it can theoreticcaly be a true constant without address.

[440bx]

The lowest possible (and usable) address depends on the O/S.

In the Windows NT family, it is $10000 thus making the first 64K of address space inaccessible.  I don't remember what it was in the Win 9x family but, I believe it was the same value.

NOTE: the $10000 value is valid for both, 32 bit and 64 bit executables.  IOW, the usable address space starts at that address regardless of bitness.

In other O/Ss, I have no idea.

HTH.

[Thaddy]

We have to google for that.. I only know it is implemented as an address.

[alpine]

Hi
What would be the lowest possible valid pointer address in a freepascal program, expressed as a PtrUInt?!?
i.e.: start of address space...
edit: 64bit ...and Linux if that matters...
Regards Benny

I've seen (known) libraries fail miserably just because of assumptions about the pointer values/ranges and using them for tagging, etc.

[440bx]

In Windows:

Load addresses are _always_ 64k aligned.  _HOWEVER_ MS has, in some instances, chosen to use the bottom 2 bits of the load address as  flags to indicate _how_ the executable was loaded.

For instance, the flags LOAD_IMAGE_AS_RESOURCE and LOAD_IMAGE_AS_DATAFILE will have some of those bits set causing any attempt to use the load address as a pointer (which is normally perfectly fine) to not yield the desired result.

if a dll or an executable is not loaded "normally" then it is a good idea to zero out, at least, the bottom 4 bits.

[MarkMLl]

I've seen (known) libraries fail miserably just because of assumptions about the pointer values/ranges and using them for tagging, etc.

Funnily enough, I was just thinking about that earlier in the context of distinguishing between an address and an integer in a component's .Tag field.

I think it's probably inadvisable to assume that /any/ range might (or might not) be an admissible address. Apart from anything else, different architectures (including consideration of both hardware and OS) will likely observe (or flout) different conventions and there are definitely types of code that would have assumed a high-end OS 20 years ago that are now running bare-metal on a microcontroller.

What can probably be assumed is that any address returned by the heap manager, i.e. all object references etc., will be even: that's probably safe even going back to TP on an 8-bit system.

So if you want to unambiguously store an integer, shift it left by one bit and set the LSB. That convention goes back to Alan Kay and the Interim Dynabook at Xerox PARC, which was based on an 8086.

MarkMLl

[cdbc]

Hi
I refined my search considerably and hit a few answers...

In the real world, good systems actually keep you from going that low; modern Linux even prevents applications from intentionally mapping pages below a configurable default (64k, I believe).

So that's in lieu with winders, or so...

Dynamic allocations are performed on heap. Heap resides in a process address space just after the text (the program code), initialized data and uninitialized data sections

...and that underlines what you guys(<pc> sorry joanna </pc>) said 

Thanks, all of you for /listening/ and answering, much appreciated =^
Your answers suits me just fine, 64k is plenty room for me to play with 
Regards Benny

[alpine]

You have been warned

rough estimation

[cdbc]

Hi
@alpine: Hehehe, good enough for me, more room to play 
Regards Benny

[PascalDragon]

For most operating systems the minimum address will likely be greater or equal to $1000, because that's the page granularity(*) and operating systems will protect virtual memory page zero so that programs will fail correctly when they dereference $0 (cause if allocated in the page tables it will be a valid address). For example I think AIX requires a special Nil-check-handling in the compiler, cause it doesn't protect page $0.

(*) If the page granularity is larger then the minimum will be larger as well

In the Windows NT family, it is $10000 thus making the first 64K of address space inaccessible.  I don't remember what it was in the Win 9x family but, I believe it was the same value.

NOTE: the $10000 value is valid for both, 32 bit and 64 bit executables.  IOW, the usable address space starts at that address regardless of bitness.

The $10000 probably comes from the fact that NT's virtual manager works on 64k chunks which in turn is a remnant from NT running on Alpha AXP.

[440bx]

The $10000 probably comes from the fact that NT's virtual manager works on 64k chunks which in turn is a remnant from NT running on Alpha AXP.

Thank you for that link.  I never had to use the Alpha instruction set as a result I wasn't aware of all the work it can take to manage addresses not aligned on a 64K boundary.

[PascalDragon]

The $10000 probably comes from the fact that NT's virtual manager works on 64k chunks which in turn is a remnant from NT running on Alpha AXP.

Thank you for that link.  I never had to use the Alpha instruction set as a result I wasn't aware of all the work it can take to manage addresses not aligned on a 64K boundary.

The Old New Thing blog is a literal gold mine of such gems of information 🥰

[440bx]

The Old New Thing blog is a literal gold mine of such gems of information 🥰

I completely agree.  I have gotten quite a few gold nuggets out of Raymond's blog too.