Re: [fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass
On 10/27/2019 08:16 PM, Martok wrote: > Am 27.10.2019 um 17:48 schrieb Florian Klämpfl: >>> I guess the main difference is whether one prefers side-by-side >>> diffs or udiffs. >> >> In particular partial commits as well as conflict resolution work much >> better with TortoiseGit for me. > > Oh yeah, conflict resolution is the thing nobody really gets right, but TGit > is > a bit less wrong. > I've pretty much resigned myself to Ctrl-F ">>>>>"... Have you tried meld? Works for me in combination with git gui -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Round function issue
On 05/23/2019 09:28 PM, Juan Carlos Díaz Vigo wrote: > I am writing to you concerning an issue that I consider as being of the > greatest importance since it affects two compiler modes of the Free > Pascal Compiler. The round function in FPC (version 3.0.4) when the > parameter is equidistant from the two nearest integers (.5) rounds the > number towards the even number. This feature of the FPC's round transfer > function when it comes to rounding (.5) integers hinders both compliance > with the ISO 7185 standard and compatibility with Turbo Pascal. What you are seeing is the so-called bankers rounding, where a halfway fraction is indeed rounded toward the even number. I was going to answer: "Use SetRoundingMode", but then I remembered that there was a thread on this list about rounding modes quite some time ago (2013), it was called "math round vs banker's round". One of the replies of that thread, given By Sevn Barth was: "Just checked again, most FPUs only seem to support "banker's rounding", "round up", "round down" and "truncate", so these four are the only ones supported by FPC's and Delphi's rounding mechanism. So if you want normal mathematical rounding then you'll need to write your own function." Since you state that there is an ISO standard that demands regular rounding (not bankers rounding), and FPC has an ISO mode, I would suggest you file a bug on this for the ISO-compliant mode. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC trunk build failed
On 17/05/18 22:22, Dimitrios Chr. Ioannidis via fpc-devel wrote: > Hi, > > I tried to build trunk today and I got the following error : > >> aasmcpu.pas(1540,31) Error: Compilation raised exception internally >> Fatal: Compilation aborted >> An unhandled exception occurred at $004B6EEE: >> EAccessViolation: Access violation > > [snip] > > Any hint ? If it's a bug should I filled a report in Mantis ? I think that when the compiler raises an exception internally, that is always worth a bugreport. It would perhaps be helpful to find the revision which started failing by eg. going back a month or so and bisect from there on. Just my 2c... -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dangerous optimization in CASE..OF
On 14/07/17 20:46, Ondrej Pokorny wrote: > Btw, when compiling this program with default Lazarus Release build mode: > [snip] > I get a warning: > > Compile Project, Mode: Release, Target: project1.exe: Success, Warnings: 1 > project1.lpr(9,1) Warning: function result variable of a managed type does > not seem to be initialized > 17 lines compiled, 0.1 sec, 34672 bytes code, 1316 bytes data IIRC that was exactly the example with which the original thread started (`Data flow analysis (dfa) and "case ... of"`). -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Ability to handle instance pointers as ordinal type.
On 02/21/2016 11:37 AM, tha...@thaddy.com wrote:
>
> 1.
> procedure TFrame00.ComboBoxChanged(Sender: TObject);
> 2.
> Var
> 3.
> x : TComboBox;
> 4.
> begin
> 5.
> If (Sender Is TComboBox) Then
> 6.
> begin
> 7.
> x := (Sender As TComboBox);
> 8.
>
> 9.
> case x.Name of
> 10.
> 'ComboBox01':if x.ItemIndex = -1 then x.ItemIndex :=
> PrjIndex else
> 11.
> begin
> 12.
> end;
> 13.
> 'ComboBox02':if x.ItemIndex = -1 then x.ItemIndex :=
> HubIndex else
> 14.
> begin
> 15.
> end;
> 16.
> 'ComboBox03':if x.ItemIndex = -1 then x.ItemIndex :=
> RimIndex else
> 17.
> begin
> 18.
> end;
> 19.
> 'ComboBox04':if x.ItemIndex = -1 then x.ItemIndex :=
> SpkIndex else
> 20.
> begin
> 21.
> end;
> 22.
> end;
> 23.
> End;
> 24.
> end;
> 25.
>
> 26.
>
> Now how much nicer it would be if you could write someting along the
> lines of:
>
> 1.
> procedure TFrame00.ComboBoxChanged(Sender: TObject);
> 2.
> begin
> 3.
> If Sender Is TComboBox Then
> 4.
> case TCombobox(sender) of
> 5.
> Combobox1:;
> 6.
> ComboBox2:;
> 7.
> ComboBox3:;
> 8.
> end;
> 9.
> end;
>
> In other words, use the instance pointer as an ordinal value.
The reason this does not work is that Combobox1, Combobox2, ... are not
constants. Replacing the strings in your first example with
Combobox1.Name, Combobox2.Name will also fail to compile.
Take this example:
=== example begin ===
Program Example;
{$mode ObjFPC}
Var
C, D: TObject;
Begin
Case ptruint(C) of
0: ;
1: ;
End;
Case ptruint(C) of
0: ;
1: ;
ptruint(D): ;
End;
End.
=== example end ===
The first case will compile, the second will not, failing with a
"Constant Expression expected". So, if you would somehow know the
instance pointers at compile time, you might get away with it ;-)
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] get/put in fpc
On 10/09/2015 08:14 PM, Schneider wrote: > > Yes, I'm currently compiling using: > > fpc -Miso -Tdarwin -Mmacpas getput.p I don't know how correct that command line is since you specify two syntax modes: iso (-Miso) and macpas (-Mmacpas). One of those will probably take precedence over the other. Judging from your other messages, you are interested in the iso mode, so try leaving out the -Mmacpas? Just a suggestion, I'm no expert on the compiler. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Future of FPCUP tool
On 07/29/2015 01:40 PM, Paul Breneman wrote: I started my first Free Pascal wiki page weeks ago: http://wiki.freepascal.org/Small_Virtual_Machines * The text below is from that wiki page * This downloads a file (875240 bytes) but can't execute it (help needed): wget https://github.com/LongDirtyAnimAlf/Reiniero-fpcup/blob/master/bin/i386-linux/fpcup_linux_x86?raw=true --no-check-certificate mv fpcup_linux_x86?raw=true fpcup The wget gives me a file called `fpcup_linux_x86`, not `fpcup_linux_x86?raw=true`, so try wget https://github.com/LongDirtyAnimAlf/Reiniero-fpcup/blob/master/bin/i386-linux/fpcup_linux_x86?raw=true --no-check-certificate -O fpcup Instead of the above two commands. (It could be specific to my system here) Now, for my system, I needed the x86_64 version: wget https://github.com/LongDirtyAnimAlf/Reiniero-fpcup/blob/master/bin/x86_64-linux/fpcup_linux_x64?raw=true --no-check-certificate -O fpcup Then chmod'ing fpcup and subsequently executing it works as expected. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] tuples
On 07/19/2015 12:30 PM, Schindler Karl-Michael wrote: Recently, I read about tuples and their use in linda for parallel programming and would like to read some more. So, can you give me a hint to the mailing list? Maybe even the year? Have a look at http://lists.freepascal.org/pipermail/fpc-devel/2013-January/031142.html -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] bitwise shift oddity a b
On 05/19/2015 04:36 PM, Adriaan van Os wrote: But, of course, I understand that CPUs implement it wrong and that the compilers writers want to be compatible with the CPU doing it wrong. That is probably the most practical solution. But that doesn't make it less ludicrous. Fast N-bit shifters (where N is a stored value in a register) are implemented in full parallel using multiplexers. The issue with that topology is that it doesn't scale well to large bit-widths: a shifter allowing for 64 shifts at once needs twice as many logic as a shifter only allowing 32 shifts at once. More logic = more time needed = more power consumption = more resources needed. So, making the common case fast (where N is a low number), simple logic dictates a smaller, simpler shifter - nothing wrong with that. So in those few rare cases where you actually want to shift something 42 bits, do it in two operations, manually. I do agree code can become messy when targeting multiple platforms, but that is, IMHO, a logical difference between platforms, just like floating point arithmetic: using SSE instructions instead of the x87 instruction set, different results are obtained (and that is the /same/ platform :-) ). -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ThousandSeparator
On 11/25/2014 07:36 PM, Hans-Peter Diettrich wrote: I'd assume that national separators are part of the according codepage, but is that always true? Of the OS/window manager actually. You are of course right in that there are a certain set of separators that can be used, but the exact separator to use is dependent on the system. Most OS's contain some form of configuration for this (`Country/Region Language` in KDE, `Language Text` in OS X, `Regional And Language Options` in Windows XP). So for visualization purposes and integration into the OS/WM, national seperators are to be fetched from the system, just as keyboard layout, to make an analogy. Note that by stating the above I in no way mean to say that this `fetching` should be done automatically. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
On 09/22/2014 08:28 PM, Boian Mitov wrote: In general, records and classes are inherently the same thing (and in C++ are indeed practically interchangeable). The only real difference in Delphi/FPC is that records are instantiated in the stack, Or on the heap: == Type TMyRecord = Record End; PMyRecord = ^TMyRecord; Var a: PMyRecord; Begin a:= GetMem(SizeOf(TMyRecord)); End; == the objects in the heap, If you alocate them like == Type TMyObject = Object End; Var a: TMyObject; == `a` will be on the stack, not on the heap. I you allocate them using `New`, they will be on the heap. See, that is what I love about this language and this compiler: you can do whatever you want! You want to write assembly: go ahead, wanna think higher level: you get a wonderful assortment of available primitives: - Dynamic arrays/strings - Static arrays/strings - Records - Objects - Classes - Interfaces Al with their own unique flavour. It is a bit like two programmer programming assembly: - One prefers a RISC style instruction set because it is composed of a set of primitive instructions that are easy to comprehend, the CISC instructions are complex and have many pitfalls is what he/she says. - The other programmer says programming RISC is a drudgery: constantly writing the same instructions that do nearly nothing, have no special side effects, all the fun is gone. As a programmer, pick the patterns you like, use them as much as you think is appropriate and know when they are not. In pascal you can do that because of the above. So much for my little praise to pascal :-) and the artificial restriction on record inheritance. If you want a record with inheritance, use object. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
On 09/20/2014 01:42 PM, Sven Barth wrote:
On 20.09.2014 13:11, Peter Popov wrote:
Please do not reference count TObject. This is a uniquely bad and
unnecessary idea. I will switch to ANSI C if you guys do it
Please enlighten me why you think it is bad. Give reasons and don't be
like a farmer doesn't eat what he doesn't know (rough translation of
a German proverb).
I think I have a reason.
First off, I do like refcounting: I use it a lot, *where useful*.
To make TObject refcounted would mean that everything is all of the
sudden refcounted, what:
- Changes the current behavior of classes (bye bye backward
compatibility)
- Adds performance overhead to every assignment between classes:
a {TObject}:= b {TObject}; // Currently the same as a
{Pointer}:= b {Pointer};
becomes
b.IncRefCount;
a.DecRefCount;
a's Pointer to instance:= b's Pointer to instance;
Throw in the handling of race conditions between threads and the
entire thing becomes bloated IMO.
- Won't allow the user to cast to and fro between classes and
pointers (useful to pass the classes thru an external API back to a
pascal callback)
What would be handy is a seperate root class that is always refcounted,
something like TRefcountedObject or something. On the other hand some
directive that makes this class refcounted would also be a good solution
IMO (something that works for refcounting in the same way as $M does for
RTTI).
Just my 5 cents.
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Newbie question: how does the compiler know the class type of an object ( the Is operator)
On 08/23/2014 11:34 AM, Dennis Poon wrote: 8.2.13 Class types http://www.freepascal.org/docs-html/prog/prog.html#QQ2-212-239 Just like objects, classes are stored Look like it is referring to a TClass instance instead of an TObject instance but thanks a lot for pointing me into the right direction. \ No, it is referring to the difference between Type TA = Object End; and Type TB = Class End; If you type Var A: TA; B: TB; Begin End; Then TA is allocated on the stack, whereas TB will be allocated on the heap once you call TB.Create; -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Newbie question: how does the compiler know the class type of an object ( the Is operator)
On 08/22/2014 07:53 PM, Dennis Poon wrote:
Howard Page-Clark wrote:
program Project1;
uses classes;
begin
WriteLn('InstanceSize of TObject=',TObject.InstanceSize);
ReadLn;
end.
I tried and it says the instancesize is 4 (on win 32 bit).
My question actually was how does the as and is get the class type
of an object.
So, does that imply the 4 byte is used to store a pointer to the class
type and Virtual Method table?
Have a look at the documentation concerning TObject.
It's the boilerplate of TObject that does the magic. (at least at
runtime, I don't know about compile time optimizations concerning the
`as` and `is` operators)
Also, to get a better idea of the size of a TObject in memory,
SizeOf(TVmt) will get you started?
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Class property and virtual getter
On 26 May 2014, at 11:04, Michael Schnell wrote: I found out that I need to add static to the get class procedure to allow it's usage in a class property. Sorry for the noise :-[ If fact I don't understand what the additional static is necessary. I was of the op pinion that class procedures are static, anyway. Can somebody clarify ? A `Class Procedure/Function XXX;` has a hidden parameter that points to the classtype. A `Class Procedure/Function XXX; static;` doesn't have this hidden parameter. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Class property and virtual getter
On 05/26/2014 01:04 PM, Michael Schnell wrote:
On 05/26/2014 12:52 PM, Ewald wrote:
A `Class Procedure/Function XXX;` has a hidden parameter that points
to the classtype. A `Class Procedure/Function XXX; static;` doesn't
have this hidden parameter.
I see.
The hidden parameter would be accessed as Self ?
Probably, I access it through `Classtype` (from TObject), as this gives
me code that will still do the same thing if I remove the `Class` in
front of the procedure/function.
Thanks for the explanation !
Now I came across a class procedure xyz; virtual; and was astonished
that this does compile.
I suppose this means that the hidden parameter will point to the
classtype of the child instead of the parent in a derived class.
It does here (writes DoIt; on stdout):
===
Program Test;
{$mode objfpc}{$H+}
Type
TTestClass = Class
Public
Class Procedure DoIt; virtual;
End;
Class Procedure TTestClass.DoIt;
Begin
WriteLn('DoIt;');
End;
Begin
TTestClass.DoIt;
End.
===
Or am I missing something?
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extended($FFFFFFFFFFFFFFFF) = -1?
On Mon, 3 Mar 2014 18:02:35 +0100, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 03 Mar 2014, at 17:43, Ewald wrote: Alright, that I did not know. Thanks for the info. I always assumed there was an instruction FULD, but it isn't there apparently. Nevertheless, Hans-Peter's statement is wrong. FPC can perfectly convert any qword value into an extended value. It's not because something cannot be done using a single instruction, that it cannot be done at all. Yes, that is also why I wrote `I guess freepascal must have done this for me`. Nonetheless it is an interesting revelation :-) -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extended($FFFFFFFFFFFFFFFF) = -1?
On 03 Mar 2014, at 21:44, Hans-Peter Diettrich wrote: Ewald schrieb: On 03 Mar 2014, at 12:49, Hans-Peter Diettrich wrote: How (which data type) does *your* parser store untyped numerical constants? Roughly like this (syntax may be a bit awry, but you get the point): TIntegerNumber = Record Case SignedNess: TSignedNess of snPositive: UValue: QWord; snNegative: SValue: Int64; End; The parser detects wether there is a `-` in front of the constant and stores the right sign in the SignedNess field. A parser doesn't work like that - too many possible cases with unary minus. Perhaps yours doesn't, I didn't say what kind of syntax `my parser` parses... Quite frankly I don't care how my parser, your parser or fpc's parser work in detail, as long as something gets parsed. Hey, that's the purpose of a parser after all ;-) If you need an datatype for integers with more bits than provided by the compiler, you must roll your own datatype. Of coure. But nobody stipulated that I can't use native pascal types (like qword, int64, byte, ...) for storing this. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extended($FFFFFFFFFFFFFFFF) = -1?
On 03 Mar 2014, at 12:49, Hans-Peter Diettrich wrote: Ewald schrieb: On 03 Mar 2014, at 00:29, Hans-Peter Diettrich wrote: `-1` would then be $1 , whereas $ would be $0 . It really is quite easy to store it like that and `fix` things [picking a fitting datatype] afterwards. The datatype has to be constructed/determined first, and *if* there exists a type with more than 64 bits, then it will be a signed type, with a 65 bit (unsigned) subrange matching your needs. But if no such type exists, you are lost. Yes, that is true, but there always is a 64 signed/unsigned type (perhaps not native). On machines where, for example, only 32 bit wide datatypes are allowed, the virtual subrange should be 33 instead of 65 bytes. Subranges are expressed in low..hi notation, not in bits, meaning that the hi value must be expressable in a valid signed positive number. That is why is use the word `virtual`. It is of course a more complex datatype than simply a subrange. See below. Anyway, that is the way how I parse constants. The important rule here is that you don't need the full 65 bit in the final representation. The signedness of the type can fix this loss of the one bit. How (which data type) does *your* parser store untyped numerical constants? Roughly like this (syntax may be a bit awry, but you get the point): TIntegerNumber = Record Case SignedNess: TSignedNess of snPositive: UValue: QWord; snNegative: SValue: Int64; End; The parser detects wether there is a `-` in front of the constant and stores the right sign in the SignedNess field. IMO your problem arises from the fact that a bitpattern, with the highest of 64 bits set, cannot be stored in a larger (signed) type, as required. Yes, spot on :-) All such untyped constants will cause problems when assigned to typed variables. Test yourself what happens when you convert such an QWORD value into Extended. That was the first example of this thread. The effect is the QWord becomes the mantissa of the extended, the exponent is set right and the sign bit is set to zero. But I believe the compiler must do this for me since (as you mention at the bottom of this quote) there is no instruction to load an unsigned integer into the 8087. then it's obvious that such a textual representation should cause an compilation error not portable We know that such an error message has not yet been implemented, but if you insist on writing unportable code... :-] I insist on using a constant that is: - 64 bit wide - Only contains 1's - Is interpreted as an unsigned number wherever mathematical operations are performed. Then you have to choose a different language. What will C++, C# or Java do in these cases? Java I'll ignore, my C# is way too rusty and C/C++ won't parse the constant as is, because it overflows the normal 32 bit range. Here you have to type something like 0xLLU. I haven't tried casting the bugger into a float though. Those demands are quite portable, no? No. Alright, let me rephrase my demands: - I want to store the value 18446744073709551615 in any kind of variable without loss of precision. Both set of demands are fine by me. Is that a more portable demand? ;-) My original problem was easily solved with a typecast QWord(gargantuan constant goes here), so that was no longer an issue. What baffled me though was the fact that this (mis-: in my opinion) mis-parsing of certain constants is by design. What you observed was related to the argument passed to WriteLn. When WriteLn includes code to output a QWord, then the output should reflect the bitpattern (unsigned number). The output of an Extended value reflects the value converted from integral to floating point, and that conversion assumes signed values. IIRC the x87 FPU doesn't have an instruction to load unsigned integral values, so that no compiler has a chance to make it load an unsigned value. Alright, that I did not know. Thanks for the info. I always assumed there was an instruction FULD, but it isn't there apparently. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extended($FFFFFFFFFFFFFFFF) = -1?
On 01 Mar 2014, at 18:17, Jonas Maebe wrote: On 01 Mar 2014, at 01:19, Ewald wrote: That is perfectly true. But shouldn't the most basic behaviour of a language be at the very least intuitive? It should be well-defined and consistent. One of Pascal's basic principles is that the native signed integer type is used for pretty much everything. While we (and Borland/CodeGear/Embarcadero) have extended the language beyond that (e.g. we support int64 on 32 bit platforms, and there's also the qword type), this principle is still followed as much as possible. In this case: constants are always preferably interpreted as signed numbers. Talking about principles: If hexadecimal is actually used to represent bit patterns (as Hans-Peter Diettrich wrote), then the decision to use a signed type here seems to violate this (represent bitpatterns) principle, since the highest bit in a signed number has a different meaning than the other bits, where in a bitpattern all bits have equal meaning. It seems like sticking to one principle (signed integer as much as possible) actually breaks another principle (bitpattern). You do care about the signedness, because the only way to represent int64(-1) in hexadecimal is as $. And what about -$1? Or is that too far fetched? Numbers in two's complement do no consist of a single sign bit followed by a magnitude. Those top 63 '1' bits together form the - sign in this number. Yes, but this can all be solved by parsing the string and storing it with one extra MSBit (if there is a `-` in front of the constant it must be negative, otherwise it should be positive). This highest bit then reflects the sign. `-1` would then be $1 , whereas $ would be $0 . It really is quite easy to store it like that and `fix` things [picking a fitting datatype] afterwards. Anyway, then you have got backwards compatibility to take care of, since there will be someone out there who's code actually depends on this behaviour. As mentioned before, for the compiler $ fits perfectly into an int64 because it parses it using val(str,int64var,value). That is circular reasoning. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extended($FFFFFFFFFFFFFFFF) = -1?
On 03 Mar 2014, at 00:29, Hans-Peter Diettrich wrote: Ewald schrieb: It seems like sticking to one principle (signed integer as much as possible) actually breaks another principle (bitpattern). Wirth and his Pascal language are well designed with signed types above all, and unsigned types being subranges. In so far one could consider hex constants with the sign bit set as syntactical errors. Well, a warning or something like that (note, hint?) would be welcome indeed. Something like `Your constant will probably not be interpreted like you expect it due to []`. You do care about the signedness, because the only way to represent int64(-1) in hexadecimal is as $. Negative numbers never should be expressed in hex. Agreed, if one wants a negative number, one should put a `-` in front of it. And what about -$1? Or is that too far fetched? That's correct, because -$1 is -1 is a valid integral expression, without signedness problems. Yeah, that is what I thought as well... This highest bit then reflects the sign. The sign representation is machine specific, as you know. On 1's complement machines there exist two representation of zero, as +0 and -0, and you cannot express both as hexadecimal constants in an portable way. Yes, but Jonas wrote that: `The internal representation of a machine is unrelated to how values in the source code are interpreted. Just like 'a' in an ASCII source file will always mean the character 'a', even if that source file is compiled for a machine that uses EBDIC. Numbers in FPC source files will always be interpreted as two's complement.` This means that the sign representation must be portable because it is always 2's complement. I suppose that the compiler will convert the representation of the sign to the appropriate notation for the machine/architecture it is compiling to. So, hence my 2's complement notation for a _potential_ type. That's why high level languages, like Pascal, forbid hex representations of (possibly) negative numerical values. That indeed would be a solution, but freepascal doesn't forbid it. Actually I am a bit opposed to forbidding stuff, so a simple warning of some sort would do just aswell for me. `-1` would then be $1 , whereas $ would be $0 . It really is quite easy to store it like that and `fix` things [picking a fitting datatype] afterwards. The datatype has to be constructed/determined first, and *if* there exists a type with more than 64 bits, then it will be a signed type, with a 65 bit (unsigned) subrange matching your needs. But if no such type exists, you are lost. Yes, that is true, but there always is a 64 signed/unsigned type (perhaps not native). On machines where, for example, only 32 bit wide datatypes are allowed, the virtual subrange should be 33 instead of 65 bytes. Anyway, that is the way how I parse constants. The important rule here is that you don't need the full 65 bit in the final representation. The signedness of the type can fix this loss of the one bit. Anyway, then you have got backwards compatibility to take care of, since there will be someone out there who's code actually depends on this behaviour. When we agree that a bitpattern of $ can be interperted differently on different 32 bit machines, as -1 or -MaxInt, Why `on 32 bit machines`? I'm fairly confident that this particular constant on this particular compiler version will generate the same outcome on every possible architecture out there (just change the `extended` to `single` in the original example, because extended tends to vary). then it's obvious that such a textual representation should cause an compilation error not portable We know that such an error message has not yet been implemented, but if you insist on writing unportable code... :-] I insist on using a constant that is: - 64 bit wide - Only contains 1's - Is interpreted as an unsigned number wherever mathematical operations are performed. Those demands are quite portable, no? My original problem was easily solved with a typecast QWord(gargantuan constant goes here), so that was no longer an issue. What baffled me though was the fact that this (mis-: in my opinion) mis-parsing of certain constants is by design. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extended($FFFFFFFFFFFFFFFF) = -1?
On 01 Mar 2014, at 03:06, Hans-Peter Diettrich wrote: Numerical constants, where the sign matters, should only be encoded in decimal. The other formats (hex,oct,bin...) are intended for use with binary values, where the bit pattern is important. Then the code compiles correctly on any kind of machine. Yeah, the only problem is that there are few calculators lying around here that can actually calculate the decimal value of $ . But you are right. If I use 18446744073709551615 instead of $ , it appears to be right. This is again what I meant with unintuitive behaviour: 18446744073709551615 should be equal to $ IMHO. Anyway, I've got this feeling that I won't be able to convince any compiler developer to fix this, so I will leave it at that. I'll fix my precompiler instead to handle this scenario for me. Assumptions about type sizes and encodings can make *application* code unportable. E.g. the Extended type doesn't have a guaranteed size and binary representation, That is true. But I don't make any assumptions about sizes of types. I use the name QWord because it happens to be largest possible unsigned integer in fpc, not because it is 8 bytes long. That is also why I started my example program with the 3 sizeof statements: to remove assumptions about datasizes. IIRC it's equivalent to Double on x64. Nowp, Double is 8 bytes long whereas Extended is 10 bytes long on this machine. Then again it doesn't matter here. Replace `Extended` in the entire thread with `Double` and you still get the same bahaviour. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Extended($FFFFFFFFFFFFFFFF) = -1?
Hi, Consider the following program (compiled using revision 26807 on OSX): === Program QWordToExtended; Begin WriteLn(Sizeof(Extended)); WriteLn(Sizeof(QWord)); WriteLn(Sizeof(Longword)); WriteLn(Extended(QWord($)));//1 WriteLn(Extended($)); //2 WriteLn(Extended(Longword($))); //3 WriteLn(Extended($)); //4 End. === Here I would expect four rather large values on standard output. The thing is that the second test gives me -1. I suspect this is due to the compiler interpreting the constant as an Int64; this is confirmed by the first test. Since I was curious as to the intended-ness of this behaviour I wrote the second set of tests which show me that this is not true for longwords: both 3 4 give the same result. This lead me to the conclusion that this is a bug. Shall I file it? Some important note, I think: the first sizeof's of the example return 10, 8, 4 on this machine. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extended($FFFFFFFFFFFFFFFF) = -1?
On 28 Feb 2014, at 20:39, Jonas Maebe wrote: On 28 Feb 2014, at 20:21, Ewald wrote: Since I was curious as to the intended-ness of this behaviour I wrote the second set of tests which show me that this is not true for longwords: both 3 4 give the same result. This lead me to the conclusion that this is a bug. Shall I file it? All hexadecimal constants are (conceptually) parsed as int64, so this is by design. int64($) is not -1. So all numeric constants that are not floats are parsed as Int64's? Isn't that view about numeric constants a bit limited (why an Int64 for example, you could've picked a virtual Int256 just as well)? Especially if you have a data type that can contain the number in it's original intention? Delphi compatibility I read in the bug report you mentioned, and I understand that in mode delphi (see below though for a bit of `issues`), but the example program is in mode fpc (or how is it called?). Can that at least be called a bug (in the documentation at the very least)? By the way, what do you do when you want to port fpc to a one's comlement machine (if they still exist)? Is $ equal to 0 then? And when you have a CPU that has a native integer size of 128 bit, how do you do the transformation then? Just truncate the constant to a 64 bit wide integer? Admitted, it are rare cases... -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extended($FFFFFFFFFFFFFFFF) = -1?
On 28 Feb 2014, at 23:43, Jonas Maebe wrote: On 28 Feb 2014, at 21:07, Ewald wrote: On 28 Feb 2014, at 20:39, Jonas Maebe wrote: All hexadecimal constants are (conceptually) parsed as int64, so this is by design. int64($) is not -1. So all numeric constants that are not floats are parsed as Int64's? They are parsed as the smallest integer type that can represent them. Ha, but an Int64 cannot represent this number. The maximum postive range of an Int64 is 2**63 - 1. The constant I used was 2**64 - 1. It doesn't fit. So this brings us to another issue: the constant cannot be represented. Yet no error or even a warning is raised. Because of the (unPascalish) decision to have an unsigned version of the largest supported integer type, there are indeed some cases that require decisions to define the behaviour That is perfectly true. But shouldn't the most basic behaviour of a language be at the very least intuitive? There is an unsigned type that can hold this constant, yet it is not used except if you use a typecast. and regardless of what decision you make, some people won't like it. I don't believe that anyone ever expected the $FXXX to become less than zero (X denotes anything from 0 to F). Its not about `liking` a decision. When we're talking about multiple inheritance, interfaces, strings, generics, we are talking about liking IMHO: everyone has his/her own coding style/habits/preferences. I have yet to meet someone who likes $FF. to be -1. Isn't that view about numeric constants a bit limited (why an Int64 for example, you could've picked a virtual Int256 just as well)? Supporting larger constant values in the compiler than what we support in the language itself would be very counter-intuitive. In a way yes, in another way it allows the compiler to be able to just interpret the number and see where it gets. The thing is that you wouldn't get this weird behaviour at all since this only happens when the constant is about as large as the maximum internal compiler representable constant. Increase this size and there would be no issue. Take, for example the number -1. This could be represented with: $1 F (take a word length of 65 bit) Then take the other constant $ , this could be represented as $0 No data is lost in this process. This mimics the exact behaviour of 32 constants. The exact datatype size can afterwards be resolved by removing either all 0's or all 1's from the left hand side of this representation. If you removed zero's, pick an unsigned datatype. Extend to the right size (1,2,4,8 for time being) with 0's. If you removed one's, it was signed. You thus need one extra bit. Pick the right signed datatype and fill with 1's on the left hand side. The only numbers that cannot be represented are -$FXXX . This could be fixed by going to a 66 bit internal datatype, but is would be pointless since there is no datatype that can represent this constant. Really, all I'm asking is one extra bit ;-) Especially if you have a data type that can contain the number in it's original intention? Hexadecimal numbers have no intention as far as signedness is concerned. That's debatable (but, as you mention, classified as part of the language definition), but a constant has a certain magnitude. It is IMO this magnitude that is the point. I don't expect a number with a lot of digits (2**64 - 1) to become rather small in magnitude (1). That is what I mean by `intention`. With this I haven't said anything about signedness: I don't care if 762 is interpreted as a signed 32 bit integer or unsigned 16 bit integer, as long as the meaning remains. If I don't want this `intention`, when performing `evil bit level hacks` (algorithms like the famous 0x5f3759df algorithm), I use a typecast to instruct the compiler how to store it. How they are interpreted is up to the language definition. Delphi compatibility I read in the bug report you mentioned, and I understand that in mode delphi (see below though for a bit of `issues`), but the example program is in mode fpc (or how is it called?). Can that at least be called a bug (in the documentation at the very least)? No, unless the documentation states that the behaviour is different for mode fpc. The behaviour, in both FPC and Delphi modes, is by design. I was looking at the wrong page (I was looking as `Numbers` instead of `Ordinal Types`). My mistake. By the way, what do you do when you want to port fpc to a one's comlement machine (if they still exist)? Is $ equal to 0 then? The internal representation of a machine is unrelated to how values in the source code are interpreted. Just like 'a' in an ASCII source file will always mean the character 'a', even if that source file is compiled for a machine that uses EBDIC. Numbers in FPC
Re: [fpc-devel] One fpc.cfg per fpc version
On 17 Feb 2014, at 10:34, Mattias Gaertner wrote: On Mon, 17 Feb 2014 00:02:11 +0100 Ewald ew...@yellowcouch.org wrote: [...] I'm not sure if that is really what you need, but I think this is the most flexible/straightforward method of `running one fpc.cfg per fpc version`. It is the most flexible, I agree with that. Most straightforward: Without the '..' it could be more straightforward, because you would not need the -n @. Well, I meant `straightforward` more with respect to usage, not with respect to the actual magick involved. This approach allows me to run any fpc version by simply running fpc-rev. number on the command line. In that respect I think it is straightforward. OTOH the involved switches seem to be a bit more exotic (as the 2.6.2 release does not even mention @, -Xp or -V in `fpc -help`) and this is indeed not so straightforward. Nonetheless, they are there and thus could be used. As to answer another question you had: No, I don't use this approach because it's the only one I know, I use it because it suits my purposes best. I looked into several other ways of running multiple freepascal compilers on my machine (almost all of which have been stated by others) and this was simply the one that required the least effort and gave me exactly what I wanted. My point is: The current search dir../etc/fpc.cfg does not work with the current defaults of make install. The following would be better: dir/etc/fpc.cfg or /etc/fpc-version/fpc.cfg or /etc/fpc.d/version.cfg This last one would introduce problems though, since all trunk version are currently version 2.7.1. Substituting version for a revision number would be possible, but it would make a terrible mess of your /etc directory IMHO. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] One fpc.cfg per fpc version
On Sun, 16 Feb 2014 19:14:33 +0100, Mattias Gaertnernc-gaert...@netcologne.de wrote: Yes, for example make install INSTALL_PREFIX=~/2.6.2 installs to ~/2.6.2/lib/fpc/2.6.2 Which looks odd. Maybe fpc should search for dir of ppcxxx/fpc.cfg. Then maybe the current search for dir of ppcxxx/../etc/fpc.cfg can be removed. Only a few people use it and they will probably be happy to have more flexibility where to install fpc. This layout is actually quite convenient, just change your path and you have a different version: The trick is basically to run fpc with two switches, and a modified $PATH: - [-n]: One that disables the default config file - [@XXX]: One that specifies where to look for the config file. (as the quoted text states this should not be required, yet somehow it was for my setup -- I'll need to look into this) So than you have something like (for revision 26651, obviously): = fpc-26651 = #!/bin/sh PATH=/compilers/fpc/26651/bin:$PATH fpc -n @/compilers/fpc/26651/etc/fpc.cfg $@ = = = I'm not sure if that is really what you need, but I think this is the most flexible/straightforward method of `running one fpc.cfg per fpc version`. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Compiling trunk on OS X
Hi, After noticing my build script all of the sudden stopped working, I tried to backtrack the issue and came to the conclusion that the following commands... === commands === [svn checkout in a clean directory] make clean make CPU_TARGET=x86_64 all === end of commands=== ... produce an unusable ppcx64 on my OS X 10.6.8 system. This only happens for revisions = 26223 (revisions 26220 - 26222 don't compile). What I mean by `unusable`: - Sometimes crashes with a segfault - Ignores command line parameters, except for the file to compile. If I give this last parameter though, the compiler never returns and starts eating up a lot of CPU usage. - I know it is rather vague... Please note that the generated ppcrossx64 *appears* to work. Anybody got some hints/suggestions on this? Some extra options to pass on to make? Some way to track the issue down to something concrete? -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling trunk on OS X
On 01 Feb 2014, at 22:18, Florian Klämpfl wrote: Am 01.02.2014 21:55, schrieb Ewald: [snip] This only happens for revisions = 26223 (revisions 26220 - 26222 don't compile). Do you really mean 26223? It looks quiet unproblematic? That is the one I mean. It could also be 26220, 26221 or 26222, but those I could not check because these don't compile (26223 is the first after this series that compiles). It indeed looks unproblematic. That is basically the reason I ask. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling trunk on OS X
On 01 Feb 2014, at 22:33, Jonas Maebe wrote: What exactly do you mean by don't compile? 26223 doesn't fix any potential compilation problems (as in syntax errors) that previous revisions might have introduced. All three fail with: cthreads.pp(360,27) Error: Identifier not found pthread_attr_destroy. Which is fixed in r26223, according to the log. It indeed looks unproblematic. That is basically the reason I ask. The only recent problem I know of with darwin/x86-64 was introduced in r26519 and was fixed in 26618. Hmmm. Then the possibilities are: - Something wrong with certain utilities? (like ar, ?) - Wrong starting compiler? (although unlikely, since the makefile would complain. I use 2.6.2) -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling trunk on OS X
On 01 Feb 2014, at 22:47, Sven Barth wrote: On 01.02.2014 22:37, Ewald wrote: It indeed looks unproblematic. That is basically the reason I ask. The only recent problem I know of with darwin/x86-64 was introduced in r26519 and was fixed in 26618. Hmmm. Then the possibilities are: - Something wrong with certain utilities? (like ar, ?) - Wrong starting compiler? (although unlikely, since the makefile would complain. I use 2.6.2) Could you please try a compiler from revision r26223 (the first one of which you said compiles again) whereby you *revert* the changes done in r26222 (the revision has x86_64 related changes, so this *could* be the problem) and report back your findings? Here you go: r26221 with the changes from r26223 compiles and runs fine. So it appears that r26222 is the culprit. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling trunk on OS X
On 01 Feb 2014, at 23:11, Jonas Maebe wrote: On 01 Feb 2014, at 23:01, Ewald wrote: Here you go: r26221 with the changes from r26223 compiles and runs fine. So it appears that r26222 is the culprit. The code changed in that revision only gets activated when targeting win64, as far as I can tell. That might be the case. My honesty obliges me to admit that my knowledge of the compiler is zip. Perhaps the two minor changes the log message talks about can shed some light on this new development? Anyway, if I can provide anything else, just ask. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling trunk on OS X
On 01 Feb 2014, at 23:25, Florian Klämpfl wrote: Just to be sure: your working copy is clean? It is clean. To be shure I first removed the entire svn tree and then checked out r26221. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling trunk on OS X
On 02 Feb 2014, at 00:05, Jonas Maebe wrote: On 01 Feb 2014, at 23:15, Ewald wrote: Anyway, if I can provide anything else, just ask. FWIW, until this is fixed you can still get a working x86-64 compiler by building it like this: make CPU_TARGET=x86_64 FPC=ppcx64 CPU_SOURCE=x86_64 all Thanks for the pointer! Would it be correct to always build the compiler like this for 64-bit targets if a native ppcx64 is available? -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc_popaddrstack ()
Once upon a time, dev.d...@gmail.com said: Does anybody have an idea what the reason could be? Perhaps: since you call the function from an `arbitrary thread`, can I assume this thread is not a `native freepascal` thread? If so, then your problem probably lies in the fact that the TLS for exception handling etc is not yet initialized. I suggest that you have a look at http://wiki.freepascal.org/Multithreaded_Application_Tutorial#External_threads Hope it helps... -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] StrToInt -- Strange behaviour
Hello,
Try running the following program and be amazed of the output:
Program Test;
Uses Sysutils;
Begin
WriteLn(StrToInt('x1'));
WriteLn(StrToInt('x0'));
WriteLn(StrToInt('xabcdef'));
End.
Apparently the StrToInt function interprets strings starting with an `x`
as hexadecimal numbers? This behaviour seems rather strange to me
(strings starting with 0x would be a bit more understandable, but then
again, we're programming pascal here, not C) and it is not mentioned in
the documentation. What do I do with it?
A- File a bug concerning incomplete documentation?
B- File a bug concerning incorrect behaviour of StrToInt()?
C- Do nothing and live with it.
D- ?
Additional information
Compiler Version: 2.6.0
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] StrToInt -- Strange behaviour
Once upon a time, Sven Barth said: On 21.02.2013 21:01, Ewald wrote: Apparently the StrToInt function interprets strings starting with an `x` as hexadecimal numbers? This behaviour seems rather strange to me (strings starting with 0x would be a bit more understandable, but then again, we're programming pascal here, not C) and it is not mentioned in the documentation. What do I do with it? IntToStr simply calls through to Val and there is documented (more or less) that it supports binary (%), octal () and hexadecimal ($, 0x) values as well (see here: http://www.freepascal.org/docs-html/rtl/system/val.html ). That it also supports 'x' and 'X' as a prefix for hexadecimal values is because of Delphi compatibility. As a sidenote: the prefixes %, and $ can be used in normal source code as well. Of course, these I use, but the `xabcd` syntax cannot be used in source code to represent numbers. Hence my confusion about what to do with it. A- File a bug concerning incomplete documentation? B- File a bug concerning incorrect behaviour of StrToInt()? C- Do nothing and live with it. D- ? I'd say A. On the one hand a reference from StrToInt(64), StrToInt(64)Def and TryStrToInt(64) to Val should be added and on the other hand Val's documentation should be extended by the fact that '0x', 'X' and 'x' are valid prefixes for hexadecimal values as well. And while we're at it references from the 32bit StrToInt variants to the 64bit variants could be added as well (they do exist the other way round as one can see here: http://www.freepascal.org/docs-html/rtl/sysutils/strtoint64.html ). So if you would please be so kind to open a bug report :) Here you go: http://bugs.freepascal.org/view.php?id=23933 :-) -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] StrToInt -- Strange behaviour
Once upon a time, Marco van de Voort said: In our previous episode, Ewald said: Apparently the StrToInt function interprets strings starting with an `x` as hexadecimal numbers? This behaviour seems rather strange to me (strings starting with 0x would be a bit more understandable, but then again, we're programming pascal here, not C) and it is not mentioned in the documentation. What do I do with it? A- File a bug concerning incomplete documentation? B- File a bug concerning incorrect behaviour of StrToInt()? C- Do nothing and live with it. D- ? E- Test with Delphi and conclude it is compatibility. So there was another option... Totally forgot about delphi compatibility ;-) -- 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?
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?
Once upon a time, on 02/07/2013 11:57 AM to be precise, Jonas Maebe said: On 06 Feb 2013, at 23:16, Ewald wrote: Concerning the locking mechanism, you can uses mutex(en/es/ii) or you can do this by a busy waiting loop with an integer (of course there are other possibilities). To elaborate on the latter a bit more: * TLockType = Integer; * Initialization: `Lock:= 0;` * Lock unlock: === Code Begin === Procedure WaitLockVar(var aLock: Integer); Begin Repeat Until InterLockedCompareExchange(aLock, 1, 0) = 0; End; Procedure UnlockVar(var aLock: Integer); Begin InterlockedExchange(aLock, 0); End; === Code End === This last code is tested and works. It only works on some platforms (and even there it may change depending on which exact processor you are using). InterlockedExchange does not guarantee any kind of memory barrier, and hence you will get occasional data races on platforms with weakly consistent memory models. You have to add memory barriers. Well, I always thought that the InterLoackedCompareExchange boiles down to [**] .Lock CMPXCHG Or something quite like that. The `.Lock` there is the important part since this does insure a memory barier. Then the only problem would be the absence of the keyword `volatile` to ensure the integer is always in the same location but I've read somewhere, long ago, that fpc doesn't perform such optimizations. So I don't see the issue really. [**] I make this assumption because the documentation says it is done in a thread safe way (reference: http://www.freepascal.org/docs-html/rtl/system/interlockedcompareexchange.html), and I don't see what other things can be made thread safe about this function except for a memory barrier. -- 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?
Once upon a time, on 02/07/2013 01:46 PM to be precise, Jonas Maebe said: On 07 Feb 2013, at 13:39, Ewald wrote: Well, I always thought that the InterLoackedCompareExchange boiles down to [**] .Lock CMPXCHG Or something quite like that. The `.Lock` there is the important part since this does insure a memory barier. It's only a memory barrier if you don't use SSE (or write-combined memory, but that's generally only the case for memory mapped video memory or so, and more of an issue for kernel mode code than for user space). Alright, this is getting interesting ;-) Yet I wonder: InterlockedCompareExchange is atomic, then you need to find a way to make sure that only one processor core (one thread in general) is accessing the memory that contains the integer/pointer. So, since InterlockedCompareExchange does not necessarily makes use of a memory barrier, how could it be done? Also, in case I misunderstood you and you are trying to say that if I write using some instruction to a part of memory that contains or is contained the integer/pointer (so there is some memory overlap) then yes, I agree and it isn't a memory barrier anymore. But then again, who writes data to a locking variable other then the code that does the locking? (same goes for a simple `lock:= 5;` for example) Furthermore, FPC supports many more architectures than just x86, and on (virtually?) all other platforms the instructions for atomic accesses do not automatically imply any kind of memory barrier. Of course, I only used this piece of pseudo-assembly since it conveys the message enough to understand each other. -- 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?
Once upon a time, on 02/07/2013 03:11 PM to be precise, Jonas Maebe said: The interlocked* routines only guarantee that that particular value is updated in atomic way across multiple cores. It does not guarantee anything about memory access performed before or after that interlocked* call. The memory barriers are to ensure that all memory accesses before the lock-primitive (such as Enter/LeaveCriticalSection) are also synchronized across all cores. Right, I see your point, should be documented if you ask me (like `This call doesn't guarantee any kind of memory barrier.`). Altough I still don't see how you can make these calls atomic then (without the barrier)? I guess I'll have to take a peek at the source code for these calls on different platforms/architectures... -- 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?
Hello, You can use some structure to lock an integer. `Some structure` can for example be a mutex, a critical section, some busy waiting loop based on CMPXCH, etc... Say that you lock the integer by calling `Lock;` and you unlock it by calling `UnLock;`. Then you can define a class TSemaphore like this: === Code Begin === Type TSemaphore = Class Private DaValue: Integer; Lock: TLockType; Public Constructor Create;// sem_init Function GetValue: Integer;// sem_getvalue Procedure Post; // sem_post Function TryWait: Boolean; //sem_trywait End; Constructor TSemaphore.Create; Begin inherited Create; DaValue:= 0; //Initialize lock here to unlocked state. End; Function TSemaphore.GetValue; Begin Lock; Result:= DaValue; UnLock; End; Procedure TSemaphore.Post; Begin Lock; DaValue+= 1; UnLock; End; // True if the semaphore is hereby decremented; false otherwise Function TSemaphore.TryWait: Boolean; Begin Lock; If DaValue 0 Then Begin DaValue-= 1; Result:= True; End Else Result:= False; UnLock; End; //True if this function returned immediately, false otherwise. Function TSemaphore.Wait: Boolean; Begin Result:= True; While True Do Begin Lock; If DaValue 0 Then Begin DaValue-= 1; Break; End; Result:= False; UnLock; End; End; === Code End === The only function missing is sem_timedwait, but this could easily be implemented by combining `nanosleep`, `trywait` and `timeofday`. NOTE: The above code is not tested, it more of a thing which I just wrote, so you will probably find some syntax errors and possible race conditions; altough I doubt the latter. Concerning the locking mechanism, you can uses mutex(en/es/ii) or you can do this by a busy waiting loop with an integer (of course there are other possibilities). To elaborate on the latter a bit more: * TLockType = Integer; * Initialization: `Lock:= 0;` * Lock unlock: === Code Begin === Procedure WaitLockVar(var aLock: Integer); Begin Repeat Until InterLockedCompareExchange(aLock, 1, 0) = 0; End; Procedure UnlockVar(var aLock: Integer); Begin InterlockedExchange(aLock, 0); End; === Code End === This last code is tested and works. Hope it is of any use. Once upon a time, on 02/06/2013 08:24 PM to be precise, Graeme Geldenhuys said: It case I'm overlooking something critical, has anybody else done something like this. If so, anybody willing to share that code - saving me some time in developing, unit testing and debugging my own Object Pascal based semaphore. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Weird output from fpGetErrNo
Once upon a time, on 01/30/2013 11:34 PM to be precise, Marco van de Voort said: The function that seemingly doesn't work is the native fpGetErrNo (with native I mean the function that is available in unit baseunix without any modification). That only works for routines that call the FPC syscall.do_syscall function directly or indirectly. Just like cerrno works for functions that call libc functions directly or indirectly. Right, I understand. So, on this linux, after calling a syscall which I defined as `external 'c'` Not a syscall, but a libc call. Even though it might call a syscall internally. Yes, of course. (like the madvise in the original post) it makes no sense to call fpGetErrno, and instead I should call fpgetCerrno to get sensible results? Correct. Or write madvise out as a true syscall, calling syscall.do_syscall (if there is any). Not all libc calls are direct syscalls. That won't be necessary I think, the `external 'c'` approach (which thus wraps the syscall up in a c function) is good enough for me. The only problem I had had to do with the errno, but that was due to me using the wrong getErrNo function. If the above is right, than errno (without the `C`) contains a leftover error from somewhere before in the program. All errno's are not cleared in any way, but should be checked _only_ if a function returns a value that indicates so (usually -1 but sometimes null) That indeed sounds obvious. What bothers me is: what (and why) created the contition? You can't know. Any library call might call several other functions that update errno internally. Schematically, it could be like this: [snip] All three somefuncs might write errno, and somelibccall simply passes the result of those calls on (and leaves their error unmodified, except in the last case). Moreover, it can write errno from nowwhere. In such cases it is impossible to tell what of these cases happened from the result of somelibccall and errno. I understand, so there probably is no issue in preceding code then, which means that I can hereby cross out this issue on my todo-list :-) Thanks for the help! -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Weird output from fpGetErrNo
Once upon a time, on 01/30/2013 11:38 PM to be precise, Tomas Hajny said: If the above is right, than errno (without the `C`) contains a leftover error from somewhere before in the program. What bothers me is: what (and why) created the contition? (I know it is not some garbage data in the variable, since it changes over time to another error: ENOTTY -- ENOENT) I don't think you need to worry too much. It's perfectly normal that certain functions used within RTL, etc., may end up in a failure code. Sometimes there's no other way for testing certain things than simply trying them and checking the result afterwards (and this may happen within the RTL and RTL itself needs to evaluate what should be cinsidered an error and what not). This had actually occured to me, it wouldn't surprise me for example that after calling `FileExists(a nonexistant filename)` you get ENOENT (No Such File Or Directory) in errno as a leftover from FileExists, which has interpreted this code and so decided to return false. In this case ENOENT no longer has any meaning (or use for that matter). But then there is ENOTTY. Where could it come from was what I was wondering about, but as you and Marco say, I shouldn't worry too much about it. And, since the program works flawlessly, it would be useless to go out on a witchhunt chasing errors which most probably aren't errors at all. Anyway, thanks for the explanation! -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Weird output from fpGetErrNo
Hello, I was just writing a little mmapped (that's two `m`'s -- no typo ;-) ) file stream and thought to do it properly just in case I might fork(). So I thought to give some advise about memory: madvise(daBuffer, FileSize, MADV_DONTFORK); Now if I check the result value and, if 0, print the detailed error code using: ErrorCode:= fpGetErrNo(); WriteMsg(strError(ErrorCode)); I get the most ambiguous results (ENOTTY, ENOENT, which are not even documented as being possible error comditions after this call). After some research I decided to try implement fpGetErrNo myself using (straight from errno.h -- using linux 3.7.4 running x86_64 hardware): Function __errno_location: pcint; cdecl; external 'c' name '__errno_location'; Function fpGetErrNo: cint; Begin Result:= __errno_location()^; End; And this gave me the expected results (Out of memory, Success, ...). So, did I discover a bug or do I miss something? Just for the record: `daBuffer` is just mmapped in the line preceding this one, there is no error there, it contains the right data, `Filesize` is obtained through stat(), so no issue there either. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Weird output from fpGetErrNo
Once upon a time, on 01/30/2013 08:17 PM to be precise, Marco van de Voort said: In our previous episode, Ewald said: I was just writing a little mmapped (that's two `m`'s -- no typo ;-) ) file stream and thought to do it properly just in case I might fork(). So I thought to give some advise about memory: Why not simply use fpgetcerrnp in unit initc? I didn't know it existed. I get the most ambiguous results (ENOTTY, ENOENT, which are not even documented as being possible error comditions after this call). What do you see if you strace the resulting binary? When explicitely triggering an error: (madvise(0, 4096)) madvise(0, 4096, 0xa /* MADV_??? */)= -1 ENOMEM (Cannot allocate memory) And when using madvise() correctly: madvise(0x7f5352248000, 31160801, 0xa /* MADV_??? */) = 0 Native fpGetErrNo gives ENOENT / ENOTTY respectively, while my little experiment gives me ENOMEM / 0 (success) respectively. fpgetcerrno from initc gives me the correct results as well; and by looking at the code I see it implements it by using `__errno_location` under linux, so no surprise there. So, what's supposed to be the difference between fpgetcerrno and fpgeterrno (multithreading? [*])? [*] Maybe not important, but this is a rather heavily multi-threaded application. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Weird output from fpGetErrNo
On 30 Jan 2013, at 21:52, Marco van de Voort wrote: In our previous episode, Ewald said: fpgetcerrno from initc gives me the correct results as well; and by looking at the code I see it implements it by using `__errno_location` under linux, so no surprise there. Well, the surprise is that initc worked, and yours not. From a quick glance I believe it to be correct too. I believe there is a bit of confusion: my little experiment and the fpgetcerrno both boil down to exactly the same code (both using __errno_location under linux). The reason I wrote it is that I didn't know it was already implemented this way in initc. Both functions obviously work. The function that seemingly doesn't work is the native fpGetErrNo (with native I mean the function that is available in unit baseunix without any modification). So, what's supposed to be the difference between fpgetcerrno and fpgeterrno (multithreading? [*])? Platform dependent. They can be the same. FPC does its own kernel calls on some platforms, and the result is then stored in fperrno. That's handy, so it would be advisory to use fperrno as much as possible then. fpcerrno is always linking to libc's errno. On platforms where FPC uses libc to acces the kernel, errno=cerrno. Thus on linux fpc does its own kernel access then, since errno cerrno? So, on this linux, after calling a syscall which I defined as `external 'c'` (like the madvise in the original post) it makes no sense to call fpGetErrno, and instead I should call fpgetCerrno to get sensible results? If the above is right, than errno (without the `C`) contains a leftover error from somewhere before in the program. What bothers me is: what (and why) created the contition? (I know it is not some garbage data in the variable, since it changes over time to another error: ENOTTY -- ENOENT) -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)
Once upon a time, on 01/07/2013 12:39 PM to be precise, Michael Schnell said: On 01/05/2013 12:28 PM, Jonas Maebe wrote: Using whatever #xx#xx or #xx#xx#xx sequence represents the UTF-8 encoding of that character. Sorry, I can't follow. Does #xx not just define a numerical representation of an 8 bit entity ? The interpretation in any code might be done later by any code that digests the string. Am I wrong ? I *think* Jonas is trying to say that if you want the character `Ǿ` in a string you would either type - 'Ǿ' or - #$C7#$BE if you want to keep the source free of encoding specific characters You as a programmer make up what you do with it afterwards, if you decide to write it to an UTF-8 terminal, you would get `Ǿ`, and if you write it to some other terminal you might see a character that matches $C7, followed by a character that matches $BE in the lookuptable of the encoding of the terminal. Look at it this way: the byte sequence ($C7, $BE) has got no meaning to the compiler whatsoever, it is a byte sequence. That's what matters to the compiler, what is in this sequence is for you to decide. Correct me if I'm wrong. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)
Once upon a time, on 01/07/2013 02:17 PM to be precise, Michael Schnell
said:
So the ambiguity with _filling_ a string with data in fact arises
when _not_ using the #nn notation :-) . With #nn the effect (i.e. the
resulting binary) is obvious.
Well, if there is literally the sequence $C7, $BE in your source code
(that is, open up a hex editor and actually see the values there, as one
byte each) that would also do the same, as the compiler will default to
one byte strings I think. The only issue with this is that you also need
to set your code editor to the encoding you want 'cause otherwise it
will screw up the display and possible binary value of the character.
So, yes I would say the #nn notation is probably the safest to use, also
handy if your character contains (or is) something that `cannot be
there`, like a newline: #10 (or #13#10 under windows)
Also, if you use a literal utf-16 char in the code (so no #, but the
actual character) I think the {$codepage utf16} directive might come in
handy, as otherwise the compiler will interpret this series of bytes as
sperate single bytes characters. This is however not an issue with the
# notation, as there is no ambiguity with this interpretation.
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)
Once upon a time, on 01/07/2013 05:05 PM to be precise, Tomas Hajny said: On Mon, January 7, 2013 14:19, Michael Schnell wrote: On 01/07/2013 02:01 PM, Tomas Hajny wrote: (also just my understanding of what Jonas wrote) I feel you are wrong. The string does not know about the code it's content is to be interpreted in (other than with Delphi XE). Sorry, your way of quoting makes it difficult for others to react. I freely admit that I may be wrong, but I don't understand what you meant with your comment and thus I don't understand in what way you I am wrong in your view. The compiler obviously knows how the constant is used within the source code and thus it may proceed accordingly (i.e. either convert it to some 8-bit encoding at compile time if UTF-16 code constant appears in the source, or keep it in UTF-16 if assigned to a UnicodeString constant). Yep, the compiler does know how the constant is used and how it is defined (how else could it generate working code?), but I don't see how it could do something with it if it is assigned to another type of string (by type I mean `one-byte versus two-byte`). The compiler can't know for sure what you mean, it can do at least these things: - Copy data without translating, so a one char two-byte string becomes a two char one-byte string; a three char one-byte string would become a three char two byte string; and then there is a pardox: should a three-char two-byte string become a six-char one-byte string? == this is probably not how it is done - Translate the meanings of the characters of the string, but here the compiler needs to know in what encoding they are and in what encoding the string is wanted. (which it doesn't I believe; the $codepage directive is only used for the encoding of the characters in the unit intself) == I think this also isn't a a possibility - Copy the data byte per byte, but then a one-byte string containing an uneven amount of chars needs padding + there are issues with endianness here == Not really an option no? - Truncate every value of a two-byte string to convert it two a one byte string; the other way around would put each character of the one-byte string as one in the two-byte string == Solves the first paradox, but introduces loss of data == All the above options (except the translation, that is) ignore the escape charachter(s) of the string, so you wont get the data you want. IMO I don't think it (typecasting a one-byte string to a two-byte string) can be done without human intervention. Look at it this way: typecasting a thread handle to an integer makes no sense either: - They are both related (a thread handle is definitely a number, even if it is a pointer) - But putting one in the other makes no sense at all: what does `comparing whether a thread id is less than zero` mean? on the other hand `comparing whether an integer is less than zero` has a distinct meaning. - The sizes may be different (say an integer of 16 bit long and a thread handle of 64 bit long), how do you put one in the other? Sum the bytes together? Multiply them? Take the 16 bit CRC of the handle? This is IMO the same with a one-byte char and a two byte char: - They both represent letters/words/... - But they are not the same and cannot be typecasted without extra knowlegde. This last point is also valid for my example above: you could put all thread ids you know of in a lookup-table and put the index in that lookup-table in the 16-bit integer. Fixed. Same goes for our strings: if you know one is UTF-8 and you want to convert it to UTF-16 it can be done without error, but without this extra knowledge it can't give you decisive results. Just a few points I think bear some potential to contemplate over a cup of $c0ffee ;-) -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] AMD Intel CPUCount
Hmmm, that's weird. The results of the Xeon are what I was expecting.
Quite frankly I don't know how to fix it. Maybe getting the maximum
amount of threads sharing the caches might prove helpfull, but then
again it is guesswork. Anyway, can you give this code a try?
Than if I take the highest value from this and the previous program it
*might* provide a sensible result. (?)
program cpucount;
{$mode objfpc}
{$asmmode att}
Function GetCores: LongWord;
Var cnt: LongWord;
Begin
Asm
MOV $0, __RESULT
MOV $0, cnt
.LStart:
MOV $4, %eax
MOV cnt, %ecx
CPUID
MOV %eax, %ebx
SHR $14, %ebx
AND $0xFFF, %ebx
ADD $1, %ebx
CMP __RESULT, %ebx
JLE .LLessOrEqual
MOV %ebx, __RESULT
.LLessOrEqual:
AND $0xF, %eax
ADD $1, cnt
CMP $0, %eax
JNE .LStart
End ['eax', 'ebx', 'ecx', 'edx'];
End;
Begin
Writeln('#max threads sharing caches: ', GetCores);
End.
Once upon a time, on 12/28/2012 08:12 AM to be precise, Ludo Brands said:
Inconsistent results here with hyperthreading:
Xeon W3530 (4 cores hyperthreading) reports #CPU cores: 8.
/proc/cpuinfo lists 8 processors and 4 cpu cores
Intel Atom 230 (1 core hyperthreading) reports #CPU cores: 1 while
/proc/cpuinfo reports 2 processors and 1 cpu core.
processor: 7
vendor_id: GenuineIntel
cpu family: 6
model: 26
model name: Intel(R) Xeon(R) CPU W3530 @ 2.80GHz
stepping: 5
microcode: 0x11
cpu MHz: 2801.000
cache size: 8192 KB
physical id: 0
siblings: 8
core id: 3
cpu cores: 4
processor: 1
vendor_id: GenuineIntel
cpu family: 6
model: 28
model name: Intel(R) Atom(TM) CPU 230 @ 1.60GHz
stepping: 2
cpu MHz: 1599.570
cache size: 512 KB
physical id: 0
siblings: 2
core id: 0
cpu cores: 1
AMD Athlon X2 5600+ reports #CPU cores: 2. /proc/cpuinfo reports 2
processors and 2 cores.
Ludo
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] AMD Intel CPUCount
Once upon a time, on 12/28/2012 09:29 AM to be precise, Mark Morgan Lloyd said: Ludo Brands wrote: On 27/12/2012 23:06, Ewald wrote: Oh, and the important part: The function has been tested on a Core 2 Duo and an Intel i7, and works correctly. If someone would be so kind to test it on some other CPU's that would be great! [I'm not 100% of the hexadecimal of `AuthenticAMD` you see] Inconsistent results here with hyperthreading: Xeon W3530 (4 cores hyperthreading) reports #CPU cores: 8. /proc/cpuinfo lists 8 processors and 4 cpu cores Intel Atom 230 (1 core hyperthreading) reports #CPU cores: 1 while /proc/cpuinfo reports 2 processors and 1 cpu core. AMD Athlon X2 5600+ reports #CPU cores: 2. /proc/cpuinfo reports 2 processors and 2 cores. Also be careful of the situation where an OS supports hot-pluggable CPU cards and has been told to shut one down for maintenance. Solaris definitely does this on SPARC, I don't know about its position on x86, and I don't know about Linux's general position. Well, the code I posted here doesn't take this sort of hotplugging in account, since it returns the # processor cores per physical cpu. Also when software shuts down cpu cores these aren't reflected in the result of the function. (says intel documentation) -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Extension of TThread's interface
Once upon a time, on 12/28/2012 11:01 AM to be precise, patspiper said: On 27/12/12 22:38, Ewald wrote: Hmmm, that;s indeed quite some different output you've got there. Mine looks like this: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU E8600 @ 3.33GHz stepping: 10 microcode : 0xa07 cpu MHz : 2000.000 cache size : 6144 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dtherm tpr_shadow vnmi flexpriority bogomips: 6668.63 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: (this is repeated twice, with only `processor:0` changing to `processor:1`) Since this is the same kind of output I got on several other linux distributions/architectures(-- 32 bit versus 64 bit intel), I assumed it was kinda `standard`. Then again assume = ... Well, anyway, it's a bit trickier than I thought at first in that case. I guess one way of calculating the number of processors is to iterate through every 'processor' in the list and add 1 if 'siblings' = 'cpu cores' (no hyperthreading), and 0.5 if 'siblings' = 2 x 'cpu cores' (hyperthreading enabled). Yeah, that could work, but then again the actual format of the data may be different measured over several distributions: suppose all `:` all of the sudden become `=`? Suppose that an identifier like `processor` undergoes a slicht namechange to `processorid`? As I said, I didn't know formats of /proc/cpuinfo differ over distributions/os'es, so it isn't safe to use this approach since all of the sudden a simly system update *might* just break your application. Despite your listing of cpuinfo is partial, one can deduce that you don't have hyperthreading. Quite right. :-) -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Extension of TThread's interface
Once upon a time, on 12/28/2012 06:46 AM to be precise, microc...@zoho.com said: On Thu, Dec 27, 2012 at 07:01:08PM +, Mark Morgan Lloyd wrote: Ewald wrote: Now, for the implementation of ProcessorCount I've got code here that reads the amount of processor cores from `/proc/cpuinfo` (linux only I think) and some assembly code [asmmode att] (tested on x86_64 and i386) that *tries* to get the amount of cpu cores by the use of CPUID. The In the general case, you have to be careful with this since (a) every architecture puts different info in /proc/cpuinfo and (b) the processor numbering and affinity vectors can have gaps. In the general case how is his x86 asm supposed to ever work on anything but Intel or AMD boxes? It isn't, it will need to be rewritten. But that shouldn't be a problem since most cpu's will have instuctions for - Add - Compare - Jump - Shift - Binary And - CPUID (probably not under this name, but I beleive most modern CPU's have got some kind of equivalent) The same thing goes for platform specific code by the way, you can't expect code that uses baseunix to compile without modification on a non unix box (e.g. windows). -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Extension of TThread's interface
Once upon a time, on 12/28/2012 04:41 PM to be precise, patspiper said: As I said, I didn't know formats of /proc/cpuinfo differ over distributions/os'es, so it isn't safe to use this approach since all of the sudden a simly system update *might* just break your application. True. A better bet would be to look for the code that produces the cpuinfo, and use that code directly. Agreed. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] AMD Intel CPUCount
Once upon a time, on 12/28/2012 04:25 PM to be precise, Ludo Brands said: On 28/12/2012 15:46, Ewald wrote: Hmmm, that's weird. The results of the Xeon are what I was expecting. Quite frankly I don't know how to fix it. Maybe getting the maximum amount of threads sharing the caches might prove helpfull, but then again it is guesswork. Anyway, can you give this code a try? Than if I take the highest value from this and the previous program it *might* provide a sensible result. (?) Xeon:#max threads sharing caches: 16 Atom:#max threads sharing caches: 2 On Xeon cpuid 0004 returns 0x1c004121 in rax , on Atom 0x4121 in eax. So both report 2 threads per cache. The cores per package (bits 31..26) is not coherent. Don't know how to solve that. Well, it is as you say, the `max cores per packge` just doesn't make any sense at all. How can a processor hav e a maximum of one core per physical package, while in reality it has two threads sharing the same cache? Either I'm missing something here, or the behaviour of CPUID has changed over the years. Either way: it leaves me with a method that is not 100% reliable. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Extension of TThread's interface
Once upon a time, on 12/28/2012 04:46 PM to be precise, patspiper said: Try lscpu -p At first sights that would be a worthy alternative to /proc/cpuinfo indeed. Thanks for the hint. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Extension of TThread's interface
Once upon a time, on 12/28/2012 05:59 PM to be precise, Marco van de Voort said: In our previous episode, Ewald said: cores' (no hyperthreading), and 0.5 if 'siblings' = 2 x 'cpu cores' (hyperthreading enabled). Yeah, that could work, but then again the actual format of the data may be different measured over several distributions: suppose all `:` all of the sudden become `=`? Suppose that an identifier like `processor` undergoes a slicht namechange to `processorid`? True. /proc is indeed not very desirable in general, and might vary per architecture too. Agreed. OTOH, even if CPUID works, and it is maintainable, it only is for one architecture, and in general in these cases the problem is getting it to work for the least popular targets/architectures, the most popular ones are usually easily implemented after a few googles, and also keeping them up to date is less of a problem. Yep, that's true, a few quick searches gives you something to get started. Then again I thought an cpu-specific implementation could also be quite handy since - There are no external depencies - It is OS independant Now, since apparantly the CPUID function returns ambiguous results from time to time it obviously cannot be used in a usefull manner. -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] AMD Intel CPUCount
Once upon a time, on 12/28/2012 08:27 PM to be precise, Ludo Brands said:
On 28/12/2012 20:01, Ewald wrote:
Well, it is as you say, the `max cores per packge` just doesn't make any
sense at all. How can a processor hav e a maximum of one core per
physical package, while in reality it has two threads sharing the same
cache? Either I'm missing something here, or the behaviour of CPUID has
changed over the years.
Atom 230 is one of the first atoms.
http://www.intel.com/content/www/us/en/processors/atom/atom-200-specification-update.html
lists a few bugs with cpuid but not this one.
Well, maybe we have just uncovered another bug? ;-)
Either way: it leaves me with a method that is not 100% reliable.
This uses libc but on the Xeon and Atom it gives the correct result
using debian and ubuntu:
program cpucount;
{$mode objfpc}{$H+}
function sysconf (__name : longint) : longint; cdecl; external 'c'
name 'sysconf';
const
_SC_UIO_MAXIOV = 60;
_SC_NPROCESSORS_CONF = (_SC_UIO_MAXIOV)+23;
begin
writeln('Number of processors: ',sysconf(_SC_NPROCESSORS_CONF));
end.
_SC_NPROCESSORS_CONF is defined in POSIX.2:
http://www.kernel.org/doc/man-pages/online/pages/man3/sysconf.3.html
Cool! And since it only depends on libc, it could be integrated nicely
into cthreads for that matter :-)
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Extension of TThread's interface
Great! Keep up the good work ;-) Rather funny actually... Quite some time ago I wrote my own threading mechanism and decided to break compatibility with fpc's TThread interface. Ever since I did that my own interface somehow became more and more compatible again with the implementation of TThread in fpc If I wait any longer I can simply switch back to native implementation again :-) Now, for the implementation of ProcessorCount I've got code here that reads the amount of processor cores from `/proc/cpuinfo` (linux only I think) and some assembly code [asmmode att] (tested on x86_64 and i386) that *tries* to get the amount of cpu cores by the use of CPUID. The only problem with the last one is that it isn't 100% correct, on an i7 for example, you get 16 as a result, where the result should be 8. Problem is that it is quite a lot of work to get the function to work decently, and since I didn't really was in the mood, I never fixed it (shame on me...). Anyway, this last one could shurely be used as some kind of all-round implementation for CPU's that support CPUID in `IsSingleProcessor`. If you (or anybody else) is interested, just let me know. Once upon a time, on 12/27/2012 05:23 PM to be precise, Sven Barth said: Hello Free Pascal community! I'm pleased to announce the extension of TThread's interface to bring it more on par with current Delphi versions. [snip] -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Extension of TThread's interface
Hmmm, that;s indeed quite some different output you've got there. Mine looks like this: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU E8600 @ 3.33GHz stepping: 10 microcode : 0xa07 cpu MHz : 2000.000 cache size : 6144 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dtherm tpr_shadow vnmi flexpriority bogomips: 6668.63 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: (this is repeated twice, with only `processor:0` changing to `processor:1`) Since this is the same kind of output I got on several other linux distributions/architectures(-- 32 bit versus 64 bit intel), I assumed it was kinda `standard`. Then again assume = ... Well, anyway, it's a bit trickier than I thought at first in that case. Once upon a time, on 12/27/2012 08:01 PM to be precise, Mark Morgan Lloyd said: Ewald wrote: Now, for the implementation of ProcessorCount I've got code here that reads the amount of processor cores from `/proc/cpuinfo` (linux only I think) and some assembly code [asmmode att] (tested on x86_64 and i386) that *tries* to get the amount of cpu cores by the use of CPUID. The In the general case, you have to be careful with this since (a) every architecture puts different info in /proc/cpuinfo and (b) the processor numbering and affinity vectors can have gaps. type: sun4u ncpus probed: 12 ncpus active: 12 .. CPU0: online CPU1: online CPU4: online CPU5: online CPU8: online CPU9: online CPU10: online CPU11: online CPU12: online CPU13: online CPU14: online CPU15: online -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] AMD Intel CPUCount (was: Feature announcement: Extension of TThread's interface)
Right, since the /proc/cpuinfo (a) is not available on many platforms
and (b) has no standard output format, I decided to fix the half done
CPUID approach. Here it goes (note: don't shoot me if my assembly is a
bit weird, I've only learned part of it by experimenting):
[see below]
For time being there are only two CPU kinds supported (GenuineIntel and
AuthenticAMD), in other cases it returns the # of logical CPU's. Feel
free to extend the code with other CPU ID's ;-)
Oh, and the important part: The function has been tested on a Core 2 Duo
and an Intel i7, and works correctly. If someone would be so kind to
test it on some other CPU's that would be great! [I'm not 100% of the
hexadecimal of `AuthenticAMD` you see]
program cpucount;
{$mode objfpc}
{$asmmode att}
Function GetCores: LongWord;
Begin
Asm
//Vendor ID
MOV $0, %eax
MOV $0, %ecx
CPUID
// ?= GenuineIntel
CMP $0x756e6547, %ebx
JNE .LnotGenuineIntel
CMP $0x49656e69, %edx
JNE .LnotGenuineIntel
CMP $0x6c65746e, %ecx
JNE .LnotGenuineIntel
MOV $4, %eax
MOV $0, %ecx
CPUID
SHR $26, %eax
AND $0x3F, %eax
ADD $1, %eax
MOV %eax, __RESULT
JMP .LReturn
.LnotGenuineIntel:
// ?= AuthenticAMD
CMP $0x68747541, %ebx
JNE .LnotAuthenticAMD
CMP $0x69746e65, %edx
JNE .LnotAuthenticAMD
CMP $0x444d4163, %ecx
JNE .LnotAuthenticAMD
MOV $0x8008, %eax
MOV $0, %ecx
CPUID
AND $0xFF, %ecx
ADD $1, %ecx
MOV %ecx, __RESULT
JMP .LReturn
.LnotAuthenticAMD:
//Return #logical CPU's
MOV $1, %eax
MOV $0, %ecx
CPUID
SHR $16, %ebx
AND $0xFF, %ebx
MOV %ebx, __RESULT
.LReturn:
End ['eax', 'ebx', 'ecx', 'edx'];
End;
Begin
Writeln('#CPU cores: ', GetCores);
End.
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
Once upon a time, on 11/28/2012 03:40 PM to be precise, luiz americo pereira camara said: So, i keep my points. Even because is not a big change with easy implementation that will fix the above issues. It IS a big change. There is production code out there that uses this, and this is an incompatible change. 1) The change in code can be tedious but is simple. from Attach(MyObj) to Attach(MyObj as IFPObserver) To fix incompatibility wouldn't a simple operator overload do the trick? Operator := (a: TObject): IFPObserver; or something like that? -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CThreads.pp
Once upon a time, on 11/19/2012 02:51 PM to be precise, Jonas Maebe said: On 18 Nov 2012, at 23:46, Jonas Maebe wrote: On 18 Nov 2012, at 14:24, Ewald wrote: Right, I fixed this issue by adding a very simple type declaration at the top of the unit: Type TThreadID = System.TThreadID; That I didn't think of this before... It seems that the pthreads unit redefines the tthreadid type. That one should probably be removed. I've removed it. Moreover it was only done in the *bsd/darwin, haiku and beos versions of that unit. Cool! That also explains why I didn't have the problem under linux... -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CThreads.pp
Once upon a time, on 11/18/2012 11:43 AM to be precise, Jonas Maebe said:
On 16 Nov 2012, at 19:42, Ewald wrote:
{$mode ObjFPC}, which is the same as cthreads.pp. Removal of the `@`
doesn't solve the problem. The thing that is weird about this is that
the type I use for `TThreadID` is not self defined, it comes from one of
the units used; which somehow is different from some other type that the
TThreadManager record uses. Is there a way to figure out from where fpc
gets a certain symbol via command line switch or something?
No. The easiest way to figure this one out is to open the source code in
Lazarus, and use its Find declaration functionality (by default: position
the cursor over an identifier and press alt/option-up).
Alright, I'll see what I can find, and I'll post it here when I've fixed it.
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CThreads.pp
Once upon a time, on 11/18/2012 01:23 PM to be precise, Ewald said:
Once upon a time, on 11/18/2012 11:43 AM to be precise, Jonas Maebe said:
On 16 Nov 2012, at 19:42, Ewald wrote:
{$mode ObjFPC}, which is the same as cthreads.pp. Removal of the `@`
doesn't solve the problem. The thing that is weird about this is that
the type I use for `TThreadID` is not self defined, it comes from one of
the units used; which somehow is different from some other type that the
TThreadManager record uses. Is there a way to figure out from where fpc
gets a certain symbol via command line switch or something?
No. The easiest way to figure this one out is to open the source code in
Lazarus, and use its Find declaration functionality (by default: position
the cursor over an identifier and press alt/option-up).
Alright, I'll see what I can find, and I'll post it here when I've fixed it.
Right, I fixed this issue by adding a very simple type declaration at
the top of the unit:
Type
TThreadID = System.TThreadID;
That I didn't think of this before...
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CThreads.pp
to give it a try, and of course it works, but it
is, let's admit it, a rather hackish way and a waste of good memory.
Also it doesn't really give you code that compiler everywhere. So in my
opinion it can be called `Impossible`.
You can also add a check like this to your code to ensure that you
don't make wrong assumptions:
{$if sizeof(tthreadid) sizeof(longint)}
{$error tthreadid must be at least the size of a longint for this
thread manager to function correctly}
{$endif}
This is very interesting to generate `safer` code (i.e. only perform the
typecast when there is enough memory), but it still doesn't give one a
clean solution.
And something I haven't yet investigated thoroughly:
- On Max OS X, `sem_open` appears not to be found. This might be a
simply typo of mine, but maybe there's someone with the same problem?
Where is it not found/how are you looking for it? Or are you perhaps
confusing it with sem_init, which indeed does not exist on Mac OS X?
No, it's definetly sem_open, the litteral error is:
`Error: Identifier not found sem_open`
My uses list contains the exact same units as in CThreads.pp, in the
same order, so I don't see why the symbol isn't found. Also, the entire
load of $idfdef's are also copied into my source code.
Undeffing `has_sem_open` makes the code compile.
Same goes for `SEM_FAILED`, but this is related to the very same issue I
believe.
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CThreads.pp
Once upon a time, on 11/16/2012 07:21 PM to be precise, Jonas Maebe said:
On 16 Nov 2012, at 19:15, Ewald wrote:
Well, the compiler gives this error:
`Incompatible types: got
address of function(Pointer,QWord,TThreadFunc,Pointer,LongWord,var
Pointer):^untyped;Register expected
procedure variable type of
function(Pointer,QWord,TThreadFunc,Pointer,LongWord,var
TThreadID):^TThreadRec;Register
Rather weird, no? Have I missed something? Or is this due to the fact that I
declare my threadmanager record using a typed constant?
In what syntax mode are you compiling? Keep in mind that turning a
procedure/function into a procvar is different in FPC/ObjFPC and TP/Delphi
modes (with/out the @).
{$mode ObjFPC}, which is the same as cthreads.pp. Removal of the `@`
doesn't solve the problem. The thing that is weird about this is that
the type I use for `TThreadID` is not self defined, it comes from one of
the units used; which somehow is different from some other type that the
TThreadManager record uses. Is there a way to figure out from where fpc
gets a certain symbol via command line switch or something?
No, it's definetly sem_open, the litteral error is:
`Error: Identifier not found sem_open`
My uses list contains the exact same units as in CThreads.pp, in the same
order, so I don't see why the symbol isn't found. Also, the entire load of
$idfdef's are also copied into my source code.
The sem_open declaration is included in cthreads via rtl/darwin/pthread.inc
(I know it's not actually a pthreads function, but that was the most logical
place to put it)
Copying the relevant code that is contained in `rtl/darwin/pthread.inc`
over to my code seems to fix this issue, logically. I seem to have
missed the `{$i pthread.inc}` line of the original CThreads.pp. Now, as
you said, it isn't really a pthread function, but why not putting it in
pthreads.pp? (thus copy the line {$i pthread.inc} over to pthreads.pp)
As I see it now, programmers don't have access to the symbols contained
in the include file, unless they implement them themselves.
--
Ewald
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] CThreads.pp
Hello, Some time ago I wrote my own thread implementation, and recently I went on the lookout for things I've missed in CThreads.pp in the source code of fpc 2.6.0 (FYI this is also the compiler I currently use). This way I found out about threadvar initialization and some other things I didn't know about. Very interesting! Since my thread class already did everything that was written down in CThreads.pp, I started thinking `Hey, why not just write a thread manager, to get a full implementation?`. So I did this. In this process I discovered several bugs/inconsistencies in both my implementation and that of CThreads. I'll start off with some strange things first: - In the source code of CThreads.pp there appears to be no field in the threadmanager record called `rtlEventSync`. Yet the compiler complains about the fact that this field is missing in my declaration of the TThreadManager record. This declaration looks as follows: `Const ZThreadManager = TThreadManager = (field: value; );`. - On Mac Os X 10.6.8 the compiler complains about the fact that my equivalent of the Function CBeginThread is incompatible with the one in the TThreadManager Record (The result types are incompatible, aswell as the type of ThreadId: Pointer [Linux; this is also what is typed in the source file] TThreadId [Mac OS X]). This is very strange 'cause I copied the declaration of every function over from CThreads.pp. Should be the same, no? - Declaration of `pthread_key_create` differs from Mac OS X to linux? Very weird because the documentation for both OS'es says exactly the same, which is basically this: `Type TCProcedure = Procedure(arg: Pointer); cdecl; Function pthread_key_create(key: ppthread_key_t; DestructorFunc: TCProcedure): cint; cdecl; external name 'pthread_key_create';` Then some things that seem unlogical to me: - `Procedure IntbasiceventSetEvent` contains a Try...Finally block, while there is no code inbetween that could possibly raise an exception. Why is it there? (are some signals converted to an exception? If so, why isn't this in almost every other function as well?) - Parameters `creationFlags` and `sa` in CBeginThread of CThreads.pp appear to be unused? - `Procedure CInitCriticalSection` contains the remark `No recursive mutex support :/`; which is quite weird because a recursive mutex behaves *very* differently from a normal mutex. On some implementations this means that you will all of the sudden get deadlocks where you don't expect them. The fix for this would be to remove recursive mutex support for critical sections. A patch for this would be to replace the existing code with the one attached [CInitCriticalSection.pas]. - The types of TRTLCriticalSection and TThreadID are not defined in the same unit as the thread manager, which means that creating custom implementations of these (especially true for critical sections) is impossible. As an example: suppose I want to use an integer for busy waiting as a critical section, I would define TRTLCriticalSection as an integer. Now I am stuck with pthreads' mutex, which is not handy if you want to do this kinda thing with an integer. And something I haven't yet investigated thoroughly: - On Max OS X, `sem_open` appears not to be found. This might be a simply typo of mine, but maybe there's someone with the same problem? Congratulations and thank you for reading this far ;-) If anyone could grant me some insights on one of these points it would be greatly appreciated. Long days and pleasant nights to you all. BTW: I only program unix OS'es nowadays, so don't shoot me if I missed some windows specific stuff. -- Ewald Procedure CInitCriticalSection(var CS); Begin If pthread_mutex_init(@CS, nil) 0 then fpc_threaderror; End;___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
Hello, I believe Tomas is right saying that there are some symbols missing. These funcions appear to be part of gcc's initialization/finalization equivalent for shared objects (a quick search told me this). I once had a similar issue with a symbol called `__dso_handle`, the fix for it was to declare the symbol (as there was apparantly noone using it, but a linker expecting it). If I were you, I would try to declare these to functions; but I can give you no garanties that it will help you in any way: Procedure _init; cdecl; public name '_init'; Begin End; Procedure _fini; cdecl; public name '_fini'; Begin End; Hope it helps. BTW: Is this behaviour the same with gcc version 4.6 insalled? On 10/26/2012 12:29 PM, Mark Morgan Lloyd wrote: Over the last few days I've brought my first Debian Wheezy (currently AKA testing) system up and find I can no longer compile gdbint. This prevents build completing on both 2.6.0 and trunk, even with NOGDB=1, fiddling with ./Makefile.fpc and ./packages/Makefile.fpc to remove ide and gdbint allows the build to complete. If gdbint is only used by the ide, shouldn't it be excluded if NOGDB is defined or if ide is removed at the top level? I'm reluctant to bug-report the build failure since at present I'm testing on SPARC/Linux, and the build failure (as distinct from the dependency) could be platform-specific. For the record the failure point is as below with 2.6.0: .. make -C gdbint smart make[3]: Entering directory `/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/packages/gdbint' make all LINKSMART=1 CREATESMART=1 make[4]: Entering directory `/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/packages/gdbint' /bin/mkdir -p units/sparc-linux /usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/compiler/ppcsparc -XX -CX -Ur -Xs -O2 -n -Fu/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/rtl/units/sparc-linux -Fl/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/libgdb/linux/sparc -Fo/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/libgdb/linux/sparc -Fi/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/libgdb/linux/sparc -Fisrc -FE. -FUunits/sparc-linux -Fl/usr/lib/gcc/sparc-linux-gnu/4.6 -Flinclude -Fl/etc/ld.so.conf.d/*.conf -O- -gl -vt -dsparc -dRELEASE src/gdbver.pp Using assembler: /usr/bin/as /usr/bin/ld: warning: ./link.res contains output sections; did you forget -T? /usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/rtl/units/sparc-linux/cprt0.o: In function `_start': (.text+0x58): undefined reference to `_init' /usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/rtl/units/sparc-linux/cprt0.o: In function `_start': (.text+0x5c): undefined reference to `_fini' /usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/rtl/units/sparc-linux/cprt0.o: In function `_start': (.text+0x64): undefined reference to `_init' /usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/rtl/units/sparc-linux/cprt0.o: In function `_start': (.text+0x68): undefined reference to `_fini' gdbver.pp(95,33) Error: Error while linking gdbver.pp(95,33) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted make[4]: *** [gdbver] Error 1 make[4]: Leaving directory `/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/packages/gdbint' make[3]: *** [fpc_smart] Error 2 make[2]: *** [gdbint_smart] Error 2 make[3]: Leaving directory `/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/packages/gdbint' There is no error on older Debian systems. I believe that I've got all prerequisites installed, noting that a build without ide and gdbint is OK. -- Ewald Events don't necessarily happen in chronological order; yet somehow they do persist to happen. Sometime. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] cmem Size Field
Hello, In the cmem unit I see that there is always some extra room allocated where the size in bytes of the requested memory block is stored. Also I noticted that this size is never really used. While I do see the point of the field (e.g. checking for right size parameter in FreeMemSize or some other debugging functionality), I do not see why this extra memory is needed always since the calls in the C library (malloc, free, realloc, calloc) do not need this kind of information. Am I missing something here is this a bit of left-over code? -- Ewald ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] cmem Size Field
I see... On the other hand, documentation (http://www.freepascal.org/docs-html/prog/progsu160.html) says that MemSize() should return the total amount of memory available for allocation; and can return 0 in case this functionality is not supported. In contrast, the RTL docs postulate that MemSize() should return the size of a previous allocated memory chunk. Which is what I always thought that MemSize() did. This functionality is however not mentioned in the documentation on the memory manager (see the above link)... Am I missing something here? Thanks in advance, Ewald On Fri, 19 Oct 2012 10:43:43 +0200, Jonas Maebe jonas.ma...@elis.ugent.be wrote: As you explain, the FPC heap manager is what requires this information. The MemSize function is standard functionality of the FPC heap managers, and so is checking whether the correct size is specified when calling freemem(p,size). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] cmem Size Field
Thanks, I just filed the bug: id 23165. -- Ewald On 10/19/12 16:11, Jonas Maebe wrote: I see... On the other hand, documentation (http://www.freepascal.org/docs-html/prog/progsu160.html) says that MemSize() should return the total amount of memory available for allocation; and can return 0 in case this functionality is not supported. It's probably a copy/paste error from the documentation for memavail, please file a bug report. Thanks. In contrast, the RTL docs postulate that MemSize() should return the size of a previous allocated memory chunk. Which is what I always thought that MemSize() did. Indeed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
