Re: [fpc-devel] serial.pp
Don't hijack en existing mailing List Thread. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-announce] Feature announcement: Type helpers
@Sven:
the problem is gone...
I made a new SVN run, and made a totally fresh compiler out of it. Now the
program compiles.
Maybe I didn't understand the syntax correctly: I didn't see how to get the
value inside the method?
example:
type
TLongIntHelper = type helper for LongInt
class procedure ShowValue; static;
end;
class procedure TLongIntHelper.Test;
begin
Writeln('Value=',self);
end;
var i : longint ;
begin
i:= 3 ;
.showvalue ;
end.
- Original Message -
From: Sven Barth
To: FPC developers' list
Sent: Friday, February 08, 2013 7:49 AM
Subject: Re: [fpc-devel] Re: [fpc-announce] Feature announcement: Type
helpers
Am 08.02.2013 07:22 schrieb Paul Ishenin i...@kmiac.ru:
08.02.2013 14:03, Sven Barth пишет:
0:25:46,51 G:\ob\syncdirsppc386 -vv -al -CioOrt -Cs600 -gclt
-Mobjfpc -O1 -OpPENTIUM -Fuu:\ -FuM:\u -FuC:\c\-u -FiC:\c\-u -Fuz:\-u
-Fiz:\-u -FuP:\gs\tp55\includes -Fuf:\-u -Fiu:\ -FiM:\u
-FiP:\gs\tp55\includes -Fif:\-u -FE. thelper
thelper.pas(2,33) Error: Identifier not found helper
thelper.pas(2,33) Error: Error in type definition
thelper.pas(2,33) Error: Can't create unique type from this type
thelper.pas(2,33) Fatal: Syntax error, ; expected but FOR found
Fatal: Compilation aborted
The compiler is freshly generated from the SVN
Does the compiler expect special options to invoke the record helper
feature?
Did you add {$mode objfpc} to your program?
Look at the compile string argument: -Mobjfpc
It's too early in the morning to look at command lines :)
@Gerhard: could you please check that the compiler is indeed from a current
SVN checkout?
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-announce] Feature announcement: Type helpers
08.02.13, 21:52, Gerhard Scholz wrote:
Maybe I didn't understand the syntax correctly: I didn't see how to get
the value inside the method?
By accessing Self
example:
type
TLongIntHelper = type helper for LongInt
class procedure ShowValue; static;
end;
class procedure TLongIntHelper.Test;
begin
Writeln('Value=',self);
end;
Replace your static class procedure with regular method:
procecure TLongIntHelper.Test;
begin
WriteLn(Self);
end;
Class static method is only needed if you are going to call it for the
type declaration itself like: LongInt.PrintSize:
class procedure TLongIntHelper.PrintSize;
begin
WriteLn(SizeOf(LongInt));
end;
static methods don't have a magic Self variable.
In any case I suggest to look for test which had been commited together
with Sven patch.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
Am 08.02.2013 13:32, schrieb Marco van de Voort: In our previous episode, Graeme Geldenhuys said: On 2013-02-07 17:55, Fl?vio Etrusco wrote: Not if you want high performance and multi-processor support. I'll prefer _working_ code to start. Currently semaphores are broken in FPC+FreeBSD. My implementation at least works everywhere I have tested - without hacks or jumping through loops. I think I'll apply a patch before building the releases, and point the freebsd maintainer to the patch. (upload it to the dist/2.6.2 dir) Don't forget to apply the patch to trunk as well :P Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-announce] Feature announcement: Type helpers
Am 08.02.2013 15:21, schrieb Paul Ishenin: In any case I suggest to look for test which had been commited together with Sven patch. Just in case: they are located in $fpcdir/tests/test and are named tthlpX.pp (where X is a number) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
On 07 Feb 2013, at 16:52, Ewald wrote: Altough I still don't see how you can make these calls atomic then (without the barrier)? On x86, it is impossible to perform an atomic access without a (partial) memory barrier that affects all memory (due to the behaviour of the lock prefix). On other architectures, the instructions for atomic accesses may only lock the cacheline or memory page containing the value to be atomically modified. I.e., they are only a barrier for that cacheline/page, not for the entire memory. Or not even that: older SPARC architectures only had a test-and-set instruction, which only supported switching between 0 and 1. So basically you had to use a single global lock variable, which you locked using this instruction, then you modified the atomic value using regular instructions, and then unlocked the global lock again. So any atomic update conflicted with any other atomic update, regardless of where the values were located, and there was no memory barrier whatsoever (except for this one lock variable). And it only worked if all code in the entire program made use of the same global lock variable. It's similar for older ARM CPUs. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] DAMath for 64-bit FreePascal and Delphi
Since the zlib license is compatible with the (modified) LGPL, it should be possible to reuse parts of that unit to improve/replace parts of our softfloat code in rtl/inc/softpu.pp (used on win64 and pretty every non-x86 platform). Path: aioe.org!.POSTED!not-for-mail From: WE@completely.invalid (Wolfgang Ehrhardt) Newsgroups: comp.lang.pascal.misc Subject: ANN: DAMath for 64-bit FreePascal and Delphi Date: Wed, 06 Feb 2013 08:40:38 GMT Organization: Aioe.org NNTP Server Lines: 32 Message-ID: 5112162f.5321...@news.aioe.org NNTP-Posting-Host: 2H8GDv+gP2BXBhuPU9DKHA.user.speranza.aioe.org X-Complaints-To: ab...@aioe.org X-Notice: Filtered by postfilter v. 0.8.2 X-Newsreader: Forte Free Agent 1.21/32.243 Xref: aioe.org comp.lang.pascal.misc:305 The DAMath archive contains units for double precision accurate mathematical methods without using multi precision arithmetic or assembler. The main purpose is to make the AMath functions available for 64-bit system without Extended Precision or 387-FPU, but they can be used with 32-bit systems. Native Delphi has made some of progress for the 64-bit numerical math routines (there still great inaccuracies for some functions in specific ranges), but unfortunately native FreePascal shows some very bad results: On Win64 from the 53 bits of double precision it looses up to - 28 bits for trigonometric functions (sin,cos etc, range = 1e10) - 26 bits for lnxp1 (range 0..1e-4), despite the fact that lnxp1 is specifically designed for small arguments - 13 bits for sinh (whole range) - 13 bits for exp (arg range 500..700) and more examples. On Win7/64 the 64-bit DAMath one argument elementary transcendental functions and power have peak relative errors 4.4e-16, the RMS values are 1.3e-16. DAMath is open source (zlib license) available from http://wolfgang-ehrhardt.de/misc_en.html#damath ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
Once upon a time, on 02/08/2013 04:02 PM to be precise, Jonas Maebe said: On 07 Feb 2013, at 16:52, Ewald wrote: Altough I still don't see how you can make these calls atomic then (without the barrier)? On x86, it is impossible to perform an atomic access without a (partial) memory barrier that affects all memory (due to the behaviour of the lock prefix). On other architectures, the instructions for atomic accesses may only lock the cacheline or memory page containing the value to be atomically modified. I.e., they are only a barrier for that cacheline/page, not for the entire memory. Or not even that: older SPARC architectures only had a test-and-set instruction, which only supported switching between 0 and 1. So basically you had to use a single global lock variable, which you locked using this instruction, then you modified the atomic value using regular instructions, and then unlocked the global lock again. So any atomic update conflicted with any other atomic update, regardless of where the values were located, and there was no memory barrier whatsoever (except for this one lock variable). And it only worked if all code in the entire program made use of the same global lock variable. It's similar for older ARM CPUs. Now I see, thanks for the explanation! -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
Am 08.02.2013 16:02, schrieb Jonas Maebe: On 07 Feb 2013, at 16:52, Ewald wrote: Altough I still don't see how you can make these calls atomic then (without the barrier)? On x86, it is impossible to perform an atomic access without a (partial) memory barrier that affects all memory (due to the behaviour of the lock prefix). On other architectures, the instructions for atomic accesses may only lock the cacheline or memory page containing the value to be atomically modified. I.e., they are only a barrier for that cacheline/page, not for the entire memory. This might change with Haswell though (when the new instructions are used). Or not even that: older SPARC architectures only had a test-and-set instruction, which only supported switching between 0 and 1. So basically you had to use a single global lock variable, which you locked using this instruction, then you modified the atomic value using regular instructions, and then unlocked the global lock again. So any atomic update conflicted with any other atomic update, regardless of where the values were located, and there was no memory barrier whatsoever (except for this one lock variable). And it only worked if all code in the entire program made use of the same global lock variable. It's similar for older ARM CPUs. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
On 08 Feb 2013, at 19:06, Florian Klämpfl wrote: Am 08.02.2013 16:02, schrieb Jonas Maebe: On 07 Feb 2013, at 16:52, Ewald wrote: Altough I still don't see how you can make these calls atomic then (without the barrier)? On x86, it is impossible to perform an atomic access without a (partial) memory barrier that affects all memory (due to the behaviour of the lock prefix). On other architectures, the instructions for atomic accesses may only lock the cacheline or memory page containing the value to be atomically modified. I.e., they are only a barrier for that cacheline/page, not for the entire memory. This might change with Haswell though (when the new instructions are used). It is already not a memory barrier for certain SSE instructions, that's why I wrote (partial). Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-announce] Feature announcement: Type helpers
Thanks for the help, I understood it now; I also found the test progs.
As far I see, it could already be substituted by the following constructs:
program RHelper1v ;
type
poLongint = ^ oLongint ;
oLongint = object
li : longint ;
procedure ShowValue ;
procedure put ( j : longint ) ;
Function inc : poLongint ;
end ;
procedure oLongInt.showvalue ;
begin
Writeln ( 'Value=', li ) ;
end ;
procedure oLongInt.put ( j : longint ) ;
begin
li := j ;
end ;
function oLongInt.inc : polongint ;
begin
system.inc ( li ) ;
result := @self ;
end ;
function v ( i : longint ) : polongint ;
begin
result := addr(i) ;
end ;
var
i : LongInt ;
begin
i := 3 ;
olongint(i).showvalue ;
olongint(i).put ( 4711 ) ;
olongint(i).showvalue ;
olongint(i).inc ;
olongint(i).showvalue ;
olongint(v(12345678)^).put ( 4711 ) ; // senseless, but possible
olongint(v(12345678)^).inc ;// senseless, but possible
olongint(v(12345678)^).showvalue ; // 4712?
end.
And it produces the same assembler code as the construct TYPE HELPER FOR
LONGINT
(which is definitely better readable).
The same program with type helper:
program RHelper1f ;
type
pLongInt = ^ longint ;
tLongIntHelper = type helper for LongInt
procedure ShowValue ;
procedure put ( j : longint ) ;
Function inc : pLongint ;
end ;
procedure TLongIntHelper.showvalue ;
begin
Writeln ( 'Value=', self ) ;
end ;
procedure TLongIntHelper.put ( j : longint ) ;
begin
self := j ;
end ;
function tLongInthelper.inc : plongint ;
begin
system.inc ( self ) ;
result := @self ;
end ;
var
i : LongInt ;
begin
i := 3 ;
i.showvalue ;
i.put ( 4711 ) ;
i.showvalue ;
i.inc ;
i.showvalue ;
12345678.put ( 4711 ) ; // senseless, but possible
12345678.inc ; // senseless, but possible
12345678.showvalue ; // 4712?
end.
The last 3 lines show that the type helpers allow useless code. I assume
such useless code is not catchable by the compiler.
Gerhard
- Original Message -
From: Paul Ishenin paul.ishe...@gmail.com
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Friday, February 08, 2013 3:21 PM
Subject: Re: [fpc-devel] Re: [fpc-announce] Feature announcement: Type
helpers
08.02.13, 21:52, Gerhard Scholz wrote:
Maybe I didn't understand the syntax correctly: I didn't see how to get
the value inside the method?
By accessing Self
example:
type
TLongIntHelper = type helper for LongInt
class procedure ShowValue; static;
end;
class procedure TLongIntHelper.Test;
begin
Writeln('Value=',self);
end;
Replace your static class procedure with regular method:
procecure TLongIntHelper.Test;
begin
WriteLn(Self);
end;
Class static method is only needed if you are going to call it for the
type declaration itself like: LongInt.PrintSize:
class procedure TLongIntHelper.PrintSize;
begin
WriteLn(SizeOf(LongInt));
end;
static methods don't have a magic Self variable.
In any case I suggest to look for test which had been commited together
with Sven patch.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-announce] Feature announcement: Type helpers
Am 08.02.2013 19:52 schrieb Gerhard Scholz g...@g--s.de: Thanks for the help, I understood it now; I also found the test progs. As far I see, it could already be substituted by the following constructs: program RHelper1v ; type poLongint = ^ oLongint ; oLongint = object li : longint ; procedure ShowValue ; procedure put ( j : longint ) ; Function inc : poLongint ; end ; procedure oLongInt.showvalue ; begin Writeln ( 'Value=', li ) ; end ; procedure oLongInt.put ( j : longint ) ; begin li := j ; end ; function oLongInt.inc : polongint ; begin system.inc ( li ) ; result := @self ; end ; function v ( i : longint ) : polongint ; begin result := addr(i) ; end ; var i : LongInt ; begin i := 3 ; olongint(i).showvalue ; olongint(i).put ( 4711 ) ; olongint(i).showvalue ; olongint(i).inc ; olongint(i).showvalue ; olongint(v(12345678)^).put ( 4711 ) ; // senseless, but possible olongint(v(12345678)^).inc ;// senseless, but possible olongint(v(12345678)^).showvalue ; // 4712? end. And it produces the same assembler code as the construct TYPE HELPER FOR LONGINT (which is definitely better readable). Impressive O.o I would have never thought to use objects like that. The main advantage of helpers compared to your example is that the compiler will do the type checking. The same program with type helper: program RHelper1f ; type pLongInt = ^ longint ; tLongIntHelper = type helper for LongInt procedure ShowValue ; procedure put ( j : longint ) ; Function inc : pLongint ; end ; procedure TLongIntHelper.showvalue ; begin Writeln ( 'Value=', self ) ; end ; procedure TLongIntHelper.put ( j : longint ) ; begin self := j ; end ; function tLongInthelper.inc : plongint ; begin system.inc ( self ) ; result := @self ; end ; var i : LongInt ; begin i := 3 ; i.showvalue ; i.put ( 4711 ) ; i.showvalue ; i.inc ; i.showvalue ; 12345678.put ( 4711 ) ; // senseless, but possible 12345678.inc ; // senseless, but possible 12345678.showvalue ; // 4712? end. The last 3 lines show that the type helpers allow useless code. I assume such useless code is not catchable by the compiler. If we could keep track of writes to Self and then mark the methods accordingly we could at least provide a warning or a hint. And the last line should show 12345678 hopefully :) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
