date:20100720


On 20 Jul 2010, at 00:32, theo wrote:

> Is there any support from the compiler to create arrays of, say
> 
> type ttest=(one,two,three,four);
> 
> Afair, these states could be represented with 2 bits. 00,01,10,11
> 
> So four of these items could be represented in a byte (in an array of
> ttest).

Declare the array as "bitpacked":

type
  ttestarray = bitpacked array[0..3] of ttest;

Note that dynamic arrays cannot be bitpacked.


Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Purpose of "uses ... in"?

2010-07-20 Thread Mattias Gärtner

Zitat von Zaher Dirkey :

On Sun, Jul 11, 2010 at 11:21 PM, Jonas Maebe  
wrote:

On 11 Jul 2010, at 15:47, Hans-Peter Diettrich wrote:

> I know that the "in " is part of the Delphi syntax, but what is
it really good for?
>
> AFAIK it's not allowed to "rename" units this way, and since (currently)
only absolute filenames are implemented,

That is incorrect. Relative file names do work. They are resolved relative
to the current working directory of the compiler.

It is more useful if relative to same directory of the current file, i can
move or copy my projects/lib easly without need to change the .cfg or my
project options.

Even then: If you move/rename a directory with target units, you have  
to adapt all 'in' of using units.

If you use search paths you only have to adapt one.

Mattias

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions


 On 07/19/2010 05:16 PM, Daniël Mantione wrote:


You could also work with the current thread id as a key to a pointer 
to the threadvars. 
Theoretically you can, but in praxis this is not doable for each access 
to a threadvar, as you would need to request the thread ID from the OS 
with each access to the threadvar which would be horribly slow. You 
can't store the thread ID in a global variable nor on the heap (as those 
obviously are not a threadvars) so you can store it on the stack or in  
register, which both are dedicated to each thread. As the stackpointer 
value is not known at runtime within any function, using the stack is 
not possible.So AFAI can see, without alternate OS-support, dedicating a 
register as a pointer to the threadvars, is the only viable option a 
compiler has.


AFAIK, in Linux the archs specs define which register is supposed to be 
used as a theradvar pointer by compilers. There might be some archs that 
don't define a register but a dedicated memory location, managed by the 
OS when scheduling threads and processes, to be the threadvar pointer.


However, segment registers are indeed the way libpthread resolves the 
TLS keys.

Obviously.

Yes, though I am still puzzled how it works on x86_64; it seems 
regvars there are also accessed using fs, but x86_64 prevents you from 
writing to segment registers.


In fact it is not critical that the threadvar register (with X86/32 
Linux) is a segment register, With NIOS it's just one of it's 32 general 
purpose registers. (I'm not very deep into ARM yet, but I'm quite sure 
that its similar here). So it might be the same with X86/64. The 
compiler just needs to make sure that this register is not modified ever 
and that it's used as a threadvar pointer.


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions

Michael Schnell schrieb:
> 
> AFAIK, in Linux the archs specs define which register is supposed to be
> used as a theradvar pointer by compilers. There might be some archs that
> don't define a register but a dedicated memory location, managed by the
> OS when scheduling threads and processes, to be the threadvar pointer.

Where can be a detailed specification of this found? How does it handle
dyn. loaded libs using thread vars?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions


 On 07/19/2010 08:33 PM, Hans-Peter Diettrich wrote:


Windows uses segment registers in exception handling, i.e. it should 
be possible. But the segment descriptor/selector must point to the 
correct thread-memory address in the address space, what can not be 
achieved in application code.


If Windows sets the segment registers and the application is not 
supposed to modify them (and assume them to be restored after 
preemption), maybe one of them is a pointer to some thread-dedicated 
memory area, that by can be used (or is used by the OS) to hold a 
pointer to the threadvars or to hold the threadvars themselves (if the 
size of the threadvar area is denoted in the exe file and thus known to 
the OS, which might kindly allocate it when a thread is created).


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions


 On 07/20/2010 11:16 AM, Florian Klaempfl wrote:

Michael Schnell schrieb:

AFAIK, in Linux the archs specs define which register is supposed to be
used as a theradvar pointer by compilers. There might be some archs that
don't define a register but a dedicated memory location, managed by the
OS when scheduling threads and processes, to be the threadvar pointer.

Where can be a detailed specification of this found?


I found these:
http://stackoverflow.com/questions/1460483/on-which-platforms-is-thread-local-storage-limited-and-how-much-is-available

http://www.linux-mips.org/wiki/NPTL


How does it handle
dyn. loaded libs using thread vars?


The just  compiler addresses the threadvars relative to  a register 
instead of  the pointer to the global area  with normal globals. (Or 
with X86/32 using another segment register instead of the default DS). 
So regarding the code it's just another Global area, in realtime the 
base of same is switching automatically when the thread is scheduled.


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] sub byte arrays

2010-07-20 Thread theo

Thank you Jonas.

Now I was trying if something like this would work:

TTest=(one,two,three,four);
TTestarray = {bitpacked} array [1..10] of ttest;
PTestarray = ^TTestarray;  

var lMask: PTestarray;
begin
getmem(lMask, 25);
 lMask^[99]:=three;
 case lMask^[99] of
  one:writeln('one');
  two:writeln('two');
  three:writeln('three');
  four:writeln('four');
 end;
 freemem(lMask);
end; 


It seems, to work, but it even works with commented "bitpacked".
Shouldn't this fail? How can I test this? I have all checks on which
Lazarus IDE offers, but it's still happy.
>From what I understand, this would need 400 bytes in this scenario (not
bitpacked), isn't it?

Thank you
Theo

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] sub byte arrays


On 20 Jul 2010, at 12:03, theo wrote:

> Now I was trying if something like this would work:
> 
> TTest=(one,two,three,four);
> TTestarray = {bitpacked} array [1..10] of ttest;
> PTestarray = ^TTestarray;  
> 
> var lMask: PTestarray;
> begin
> getmem(lMask, 25);

Uses new(lMask) instead, then the compiler will automatically allocate the 
right size for you.

> lMask^[99]:=three;
> case lMask^[99] of
>  one:writeln('one');
>  two:writeln('two');
>  three:writeln('three');
>  four:writeln('four');
> end;
> freemem(lMask);
> end; 
> 
> 
> It seems, to work, but it even works with commented "bitpacked".
> Shouldn't this fail?

You are writing into unallocated memory. The result of such an operation is 
"undefined". That means that it can to work, can crash, or anything in between.

> How can I test this? I have all checks on which
> Lazarus IDE offers, but it's still happy.

Have you enabled heaptrc? (-gh)


Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] sub byte arrays

2010-07-20 Thread José Mejuto

Hello theo,

Tuesday, July 20, 2010, 12:03:28 PM, you wrote:

t> Now I was trying if something like this would work:
t> TTest=(one,two,three,four);
t> TTestarray = {bitpacked} array [1..10] of ttest;
t> PTestarray = ^TTestarray;
[...]
t> It seems, to work, but it even works with commented "bitpacked".
t> Shouldn't this fail? How can I test this? I have all checks on which
t> Lazarus IDE offers, but it's still happy.
>>From what I understand, this would need 400 bytes in this scenario (not
t> bitpacked), isn't it?

Had you tried SizeOf(TTestarray) ?

-- 
Best regards,
 José

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions

2010-07-20 Thread Sven Barth


Hi!

Am 20.07.2010 11:31, schrieb Michael Schnell:

On 07/19/2010 08:33 PM, Hans-Peter Diettrich wrote:


Windows uses segment registers in exception handling, i.e. it should
be possible. But the segment descriptor/selector must point to the
correct thread-memory address in the address space, what can not be
achieved in application code.


If Windows sets the segment registers and the application is not
supposed to modify them (and assume them to be restored after
preemption), maybe one of them is a pointer to some thread-dedicated
memory area, that by can be used (or is used by the OS) to hold a
pointer to the threadvars or to hold the threadvars themselves (if the
size of the threadvar area is denoted in the exe file and thus known to
the OS, which might kindly allocate it when a thread is created).


According to 
http://en.wikipedia.org/wiki/Thread-local_storage#Windows_implementation 
you use a dedicated API to modify the TLS. And according to 
http://en.wikipedia.org/wiki/Thread_Environment_Block the address of the 
TLS is indeed accessible/saved in the segment registers.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Unit loading overhead

On 17 Jul 2010, at 21:50, Micha Nelissen wrote:

> Jonas Maebe wrote:
>> All applications but the ones that allocate a only few memory blocks 
>> (especially in case it's a few small blocks of many different sizes) would 
>> benefit from this change, not just apps allocating hundreds of megabytes at 
>> the same time (it also helps in case applications maximally use 10MB, but 
>> allocate and free a lot of data so the blocks get released back to the OS). 
>> Applications allocating a ton of them would obviously benefit more than 
>> others.
> 
> So why 256kb? not 64, 128, or 512kb?

I've now committed a dynamic scheme that starts of with chunks of 32KiB, but 
which grows the chunk size (per thread) as more and more get allocated (up to a 
limit of 256KiB). The speed is only slightly lower than when starting of 
immediately with 256KiB blocks, and for apps performing only a few allocations 
nothing changes regarding the amount of memory they use.

The 256KiB upper limit comes from benchmarking the compiler both when compiling 
itself (average scenario, mixed allocations and frees) and the "all packages 
units" (extreme scenario). Going higher did not provide noticeable speed gains 
while increasing memory usage quite a bit. The same goes for the limit of when 
the size of the chunks to allocate is doubled.

Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions


 On 07/19/2010 05:22 PM, Florian Klaempfl wrote:

The segment register approach is not officially documented


Are we discussing Win32 or Win 64 here ?

So, what is officially documented regarding restoring registers after 
preemption.


Obviously all "normal" registers and all FPU registers are restored.

CS, DS and SS obviously need to be handled appropriately and are not 
available.


Also ES needs to be restored as same is dedicated to be used for local stuff

What more do we have ?  FS, GS.

Here some documentation would be necessary.

-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions


 On 07/20/2010 12:51 PM, Sven Barth wrote:


According to 
http://en.wikipedia.org/wiki/Thread-local_storage#Windows_implementation 
you use a dedicated API to modify the TLS. And according to 
http://en.wikipedia.org/wiki/Thread_Environment_Block the address of 
the TLS is indeed accessible/saved in the segment registers.
OK. Great. A lot more complicated than with Linux, but seemingly 
decently documented.


What about Win 64 ?

-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions

Michael Schnell schrieb:
>  On 07/19/2010 05:22 PM, Florian Klaempfl wrote:
>> The segment register approach is not officially documented
> 
> Are we discussing Win32 or Win 64 here ?

At least Win32: accessing the tlb via fs does not work for all windows
with one approach.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions


 On 07/20/2010 01:42 PM, Florian Klaempfl wrote:

At least Win32: accessing the tlb via fs does not work for all windows
with one approach.


According to Stevens Post using the "Thread Information block" which is 
addressed by FS is documented and thus needs to be working for 256 
TLS-Slots (whatever that means) in NT (and supposedly higher). Who cares 
about Win9x :) .


No idea about Win64.

BTW what about GS ? If same is just restored after preemption, this 
could be used by the compiler to point to the Threadvar area.


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions

Michael Schnell schrieb:
>  On 07/20/2010 01:42 PM, Florian Klaempfl wrote:
>> At least Win32: accessing the tlb via fs does not work for all windows
>> with one approach.
> 
> According to Stevens Post using the "Thread Information block" which is
> addressed by FS is documented 

Where is it *officially" (e.g. MSDN) documented?

> and thus needs to be working for 256
> TLS-Slots 

No.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions


 On 07/20/2010 01:42 PM, Florian Klaempfl wrote:


At least Win32: accessing the tlb via fs does not work for all windows
with one approach.


The documentation  Sven mentions says:



FS:[0x2C] 4 Win9x and NT Linear address of the thread-local 
storage array





Do you suppose Vista and Win 7 will not apply ?

-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions

On 20 Jul 2010, at 14:03, Michael Schnell wrote:

> BTW what about GS ? If same is just restored after preemption, this could be 
> used by the compiler to point to the Threadvar area.

Only if you are guaranteed that no externally called code will modify it. In 
that case, you FPC itself also save/restore that register before and after 
calling any potentially non-FPC code, since other applications may make the 
same assumption. If you don't make that assumption, at the very least you still 
have to reload it after any call to potentially non-FPC code.

Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions

Michael Schnell schrieb:
>  On 07/20/2010 01:42 PM, Florian Klaempfl wrote:
>>
>> At least Win32: accessing the tlb via fs does not work for all windows
>> with one approach.
> 
> The documentation 

It is probably reverse engineered guesswork but no official documentation.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions


 On 07/20/2010 02:08 PM, Jonas Maebe wrote:

Only if you are guaranteed that no externally called code will modify it.
This should be documented in the ABI description and of course could be 
different for the different calling conventions (Register, STDCALL, 
...). If the ABI defines that GS can be modified by the callee FP should 
of course save it on the stack before calling and restore it afterwards. 
Seems like "Standard" to me.


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions


 On 07/20/2010 02:07 PM, Florian Klaempfl wrote:

It is probably reverse engineered guesswork but no official documentation.
Hmm. I think M$ wants us to do decent Applications and this includes 
multithreaded applications that use threadvars ("__thread" in C).


Thus I can't believe they did not document how a compiler is supposed to 
handle threadvars.


Also, I suppose there is a documentation for M$'s own C compiler and for 
GNU C how they do it on the appropriate arch, as same should be able to 
call ASM functions that define their own threadvars in a way compatible 
to the main program written in C. Maybe this is even true for Delphi.


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions

On 20 Jul 2010, at 14:22, Michael Schnell wrote:

> On 07/20/2010 02:08 PM, Jonas Maebe wrote:
>> Only if you are guaranteed that no externally called code will modify it.
> This should be documented in the ABI description

I don't see it there (to the extent that there is an official win32 abi 
document; it seems that information is spread over several msdn pages that 
don't even link to each other).

Please stop speculating that certain things "should be documented" or "should 
work" and post links to the official documents. Sending us off on wild goose 
chases does not help.

Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions


 On 07/20/2010 02:48 PM, Jonas Maebe wrote:


I don't see it there (to the extent that there is an official win32 abi 
document; it seems that information is spread over several msdn pages that 
don't even link to each other).
At least the "Register" ABI is FPC specific and needs to be documented 
with the compiler. I hope the others are available near that place.

Please stop speculating that certain things "should be documented" or "should 
work" and post links to the official documents.

I tried to find it in the FPC docs, but was not successful.

-Michael

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions


On 20 Jul 2010, at 15:00, Michael Schnell wrote:

> On 07/20/2010 02:48 PM, Jonas Maebe wrote:
>> 
>> I don't see it there (to the extent that there is an official win32 abi 
>> document; it seems that information is spread over several msdn pages that 
>> don't even link to each other).
> At least the "Register" ABI is FPC specific and needs to be documented with 
> the compiler. I hope the others are available near that place.

The "register" calling convention is Borland-specific and does not specify 
anything regarding the segment registers: 
http://docwiki.embarcadero.com/RADStudio/en/Program_Control

>> Please stop speculating that certain things "should be documented" or 
>> "should work" and post links to the official documents.
> I tried to find it in the FPC docs, but was not successful.

I know of no single calling convention that says anything about the segment 
registers. It's an OS ABI issue at best, and at worst undefined behaviour.


Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Blackfin support

2010-07-20 Thread Graeme Geldenhuys

On 20 July 2010 09:51, Joost van der Sluis wrote:
> On Wed, 2010-07-14 at 19:19 +0200, Marco van de Voort wrote:
>> Core is not unreasonable (*),
>
>> (*) well except me obviously, but I won't be reviewing compiler submissions,
>> so it is easier for me to say this all.
>
> Sorry for the useless post, but this is just funny. ;)

+1


   Graeme.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] sub byte arrays

2010-07-20 Thread theo

José Mejuto wrote:
> Had you tried SizeOf(TTestarray) ?

Good idea. Now I can see that the theory is right.
for: TTestarray = array [1..100] of ttest;
It goes down from 400 to 25 (using bitpacked).

Jonas Maebe wrote
> Uses new(lMask) instead, then the compiler will automatically allocate
the right size for you.

I don't think this is going to solve my problem.
I need to define the size at runtime.
With
getmem(lMask, (Elements div 4) +1);
this should be possible, right?

Thank you both.
Theo

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Question about 'const' and calling conventions

2010-07-20 Thread Joost van der Sluis

Hi all,

In a safecall method definition on win32, is a parameter with the
'const' identifier always passed by reference?

Or is it 'compiler decide' like the normal calling convention?

I need to know to be sure if the code I'm working on works on accident
or as designed. ;)

Joost.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions

2010-07-20 Thread Hans-Peter Diettrich


Michael Schnell schrieb:

BTW what about GS ? If same is just restored after preemption, this 
could be used by the compiler to point to the Threadvar area.


Since it turned out that loading segment registers is very time 
consuming on newer (i486+) processors, the memory management was changed 
from segmented (16 bit) into paged (32 bit flat). Segment registers 
never should be changed by an application, it should be left to the OS 
process/thread scheduler and thread-API calls.


DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Purpose of "uses ... in"?

2010-07-20 Thread Zaher Dirkey

2010/7/19 Mattias Gärtner 

> Even then: If you move/rename a directory with target units, you have to
> adapt all 'in' of using units.
> If you use search paths you only have to adapt one.
>

example

uses
   myunit in '..\lib\myunit.pas', ...

it is no need to change it even in the search path.

-- 
Zaher Dirkey
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Purpose of "uses ... in"?

2010-07-20 Thread Zaher Dirkey

uses

>myunit in '..\lib\myunit.pas',
>
> it is no need to change it even in the search path.
>
>
I meant my project have folders like
/proj/bin
/proj/src
/proj/lib
i can move the dir /proj or my component package to any dir without need a
changes.

The other way we can use extrafpc.cfg, we can put relative path in
"-Fu..\lib", but if you use units of packages you need to put many of pathes

Best regards
-- 
Zaher Dirkey
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Purpose of "uses ... in"?

2010-07-20 Thread Marcos Douglas

On Tue, Jul 20, 2010 at 2:50 PM, Zaher Dirkey  wrote:
> 2010/7/19 Mattias Gärtner 
>>
>> Even then: If you move/rename a directory with target units, you have to
>> adapt all 'in' of using units.
>> If you use search paths you only have to adapt one.
>
> example
>
> uses
>    myunit in '..\lib\myunit.pas', ...
>
> it is no need to change it even in the search path.

I agree.
But I agree too the search path has advantages... because that I
mentioned keep the both (today, it is, right?).

And, in addition, I sugest to implement a new syntax for units of the
same name using "IN" and "AS" as bellow:
uses
 zip IN '/units/my/zip.pas' AS myzip;
 zip IN '/units/lib/zip/zip.pas' AS ziplib;

...someone liked the idea?  :(


MD
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions

2010-07-20 Thread Sven Barth


Hi!

Am 20.07.2010 13:43, schrieb Michael Schnell:

On 07/20/2010 12:51 PM, Sven Barth wrote:


According to
http://en.wikipedia.org/wiki/Thread-local_storage#Windows_implementation
you use a dedicated API to modify the TLS. And according to
http://en.wikipedia.org/wiki/Thread_Environment_Block the address of
the TLS is indeed accessible/saved in the segment registers.

OK. Great. A lot more complicated than with Linux, but seemingly
decently documented.

What about Win 64 ?


The Linux and Windows APIs are more or less similar. The fact that the 
TLS address is stored inside a segment register shouldn't bother us / an 
app developer anyhow, because that is defined as "implementation detail" 
(the TEB is only documented by Wine devs not by Microsoft themselves 
(only the subsystem independant part of the TEB is)).
That said Win 64 uses the same API as Win 32 and the segment register 
used for the TEB is GS instead of FS.


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] OO rewrite - technical questions

2010-07-20 Thread Sven Barth

Hi!

Am 20.07.2010 14:35, schrieb Michael Schnell:

On 07/20/2010 02:07 PM, Florian Klaempfl wrote:

It is probably reverse engineered guesswork but no official
documentation.

Hmm. I think M$ wants us to do decent Applications and this includes
multithreaded applications that use threadvars ("__thread" in C).

Thus I can't believe they did not document how a compiler is supposed to
handle threadvars.

Also, I suppose there is a documentation for M$'s own C compiler and for
GNU C how they do it on the appropriate arch, as same should be able to
call ASM functions that define their own threadvars in a way compatible
to the main program written in C. Maybe this is even true for Delphi.

For this purpose the TLS-API is to be used. The segment registers that
point to the TLS array are undocumented and part of the internal
bookkeeping of a NT system (and yes, Windows Vista and 7 are NT systems
as well).
But because many applications rely on this undocumented TEB Microsoft
doesn't dare to change anything regarding this. But please no fight
about this topic; I've read the blog and the book of a Microsoft
developer who reports to what lengths Microsoft went to ensure
application compatibility (it's called "The old new thing" and I'm
suggesting it to everyone who wants to know something about Windows
internals in a humorous way).

Btw: if you are really curious you might take a look at the TLS
implementation of ReactOS, which is an NT OS after all:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/thread/tls.c?revision=45018&view=markup

Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Question about 'const' and calling conventions