Re: [fpc-devel] Building compiler, rtl, host, target... (cross compiling)
- Original Message - From: "Skybuck Flying" To: "FPC developers' list" Sent: Thursday, 7 April, 2011 03:06 AM Subject: Re: [fpc-devel] Building compiler, rtl, host,target... (cross compiling) Ok, I thought about it a bit and I think I now logically understand what's going on and what needs to happen when one wants to build a new compiler, possibly for cross compiling and such in relation to the RTL. First of all "free pascal compiler" is not a "multi-target cross compiler" but it is a "dual-target cross compiler" (dual meaning host and target can be different ;)) So starting with the basics: Suppose somebody would get the free pascal source codes only and now executables then that person would first need to Little typo here... gonna correct it: source codes only and no executables then that person would first need to compile: 1. The compiler and 2. The run time library For let's say windows. The compiler is a little bit like an application, applications need a system unit, the runtime library provides that system unit. However the "external/user compiler" might already have a system unit... so for that purposes the "external/user compiler run time library/system unit might be used". The free pascal compiler dependancies on it's own RTL could be fixed/modified/temporarely changed to use the external compiler's system unit to get the first compiler build working. So step 1 would then produce: A free pascal compiler executable which runs on windows. The target to keep things easy was set to windows to first produce a "native compiler" (which runs on windows and compiles to windows) Now the mission/job/idea is to produce a cross-compiler which can cross-compile to a new architecture/processor/platform let's called it NewCPU and NewRTL in short: NewTarget. Step 2 is a repeat of step 1. However it would be helpfull if the RTL itself was also compileable to the new target... but let's see how far we can go without it. Step 2 specifies somehow to the build enviroment that the compiler sources are to be re-compiled but this time the compiler which is build from it should compile to the NewTarget... for that the new compiler needs "new architecture support"... So that's where the new instructions and new assembler come in... and perhaps new linker... but let's start with new assembler and such... Since the executable to be produced must still run on windows it can and probably must still use the windows RTL to be able to produce the executable. If the same RTL was used to specify the target build... then it would be a bit strange because then NewCPU would try to use a Windows RTL... So this would then produce a "half-cross compiler" which would be kinda funny... it would probably be "defunct"/"not working" perhaps such executables produce by such a half compiler could be patched etc... but that's probably a bit stupid to do. What is needed is a "full-cross compiler" which also uses the NewRTL for the NewPlatform. Apperently specifieing the NewRTL can be done by compiler command line options or configuration files. Thus there are now probably two RTL's involved: One RTL for the host, One RTL for the target. How the compiler makes sense of this I am not yet sure... Perhaps it's a question of linking in the NewRTL when a NewPlatform application is being build by the new compiler. So perhaps it's the "internal linker" which needs the NewRTL to be present to do it's work ?!? How else could it work ?? However perhaps the new compiler also needs to do type checking against the NewRTL for NewPlatform applications... Thus somehow the new compiler must be using the new RTL. The new RTL didn't exist yet... so it needs to be compiled. Apperently this is where a "half-cross compiler comes in ?" The new RTL cannot depend on "other platform RTL's" ? So if I am correct in my assumption then the any RTL for that matter must be "self-standing" and not rely on anything else except it's own platform that it was written for. It must also not depend on RTL functionality itself ? How would otherwise a compiler be able to compile it ? (without creating some kind of platform depedency) So I guess this is where a "half-cross-compiler" comes in... The half-cross compiler is capable of compiling a NewRTL and producing some kind of assembly text which can then be used to compile the NewRTL to some kind of binary (a pascal unit binary?) This is perhaps where the linker also comes into play or maybe not... Anyway once the NewRTL is compiled into pascal unit binaries it can be used/include in a new compiler build. So the compiler sources are again recompiled... but this time the compiler sources are "told" or "modified via includes/search paths" to use the NewRTL units so that it itself is compiled towards the new platform and uses the new rtl for that platform. This will then produce a "full cross compiler" which i
Re: [fpc-devel] Building compiler, rtl, host, target... (cross compiling)
I have to go do other things now so I will keep this short, maybe I'll get back to this posting later on... What is needed is a "full-cross compiler" which also uses the NewRTL for the NewPlatform. No, why should the compiler need to use a different RTL, for its *own* operation? It already has an RTL embedded inside it which it is currently using to run itself. (Side question: can an RTL actually be a runtime library instead of being compiled into applications ?) However for the application which it is trying to compile needs to run on a different platform and thus the application needs to either be linked to that platform RTL or it needs to have that platform RTL embedded into it. And that's what free pascal more or less seems to do... it embeds "a target platform RTL" into the application that it tries to compile. Every compiler can compile the RTL for its target, as well as other applications. No the compiler cannot compile the RTL for it's target because the compiler does not have the assembly yet to output the RTL ? So at the very minimum the compiler needs to produce assembler output and for that it needs some kind of internal assembler-outputter ;) An alternative could be a plug-in system where the necessary assembler-outputter is plugged into. But currently free pascal works with "embedded assembler-outputters" thus the compiler needs to be re-compiled before it can use these new "assembler outputters". (Ok, you had no further comments, so this can probably be kept short ;)) Bye, Skybuck. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building compiler, rtl, host, target... (cross compiling)
Am 07.04.2011 03:06, schrieb Skybuck Flying: Ok, I thought about it a bit and I think I now logically understand what's going on and what needs to happen when one wants to build a new compiler, possibly for cross compiling and such in relation to the RTL. First of all "free pascal compiler" is not a "multi-target cross compiler" but it is a "dual-target cross compiler" (dual meaning host and target can be different ;)) The definition of "cross compiler" is that a compiler that runs on CPU A with operating system B can generate code for operating system C that runs on CPU D. Not more, not less. So starting with the basics: Suppose somebody would get the free pascal source codes only and now executables then that person would first need to compile: 1. The compiler and 2. The run time library It must be done the other way round as the compiler needs the RTL to run itself. For let's say windows. The compiler is a little bit like an application, applications need a system unit, the runtime library provides that system unit. However the "external/user compiler" might already have a system unit... so for that purposes the "external/user compiler run time library/system unit might be used". The free pascal compiler dependancies on it's own RTL could be fixed/modified/temporarely changed to use the external compiler's system unit to get the first compiler build working. There is no need to fix up anything. The process is the following: You have a starting compiler for let's say i386 and you have source code of FPC and its RTL any you want to have a new shiny i386 Windows compiler. 1. Compile the RTL using the starting compiler (after all the RTL is just Pascal source that pulls in operating system specific code) 2. Compile the compiler together with the newly compiled RTL 3. Use that new compiler to compile the RTL again (so that new features are used) 4. Compile the compiler again using the newly compiled RTL. Now you can Win32 i386 applications using your new compiler (and the RTL) One RTL for the host, One RTL for the target. How the compiler makes sense of this I am not yet sure... Perhaps it's a question of linking in the NewRTL when a NewPlatform application is being build by the new compiler. The RTL for the host is used by the compiler as it was compiled with that RTL (as every Free Pascal program is) and the RTL for the target are "just" (compiled) source files that are used(!) by the compiler to build the final executable (like it's done for every Free Pascal program). So if I am correct in my assumption then the any RTL for that matter must be "self-standing" and not rely on anything else except it's own platform that it was written for. This assumption is indeed correct. The base RTL unit (system.pp) as no dependency whatsoever and all other units inside the RTL (sysutils, classes, etc) basically only depend on the system unit. So I guess this is where a "half-cross-compiler" comes in... The half-cross compiler is capable of compiling a NewRTL and producing some kind of assembly text which can then be used to compile the NewRTL to some kind of binary (a pascal unit binary?) Every FPC compiler is able to compile the RTL. Just do a "make cycle" inside the compiler directory and you'll see that the RTL is compiled mutliple times. So if I am correct "porting free pascal compiler and rtl towards a new platform" requires the following steps: 1. Step 1 (preparing for first native free pascal compiler) Install a "external pascal compiler" so that free pascal compiler sources can be compiled. (ignore free pascal's own rtl if necessary), make changes to the free pascal compiler source code if necessary to use the external pascal compiler's RTL. The "external pascal compiler" MUST be a Free Pascal compiler as it needs to compile the RTL for the compiler first. More specifically that procedure is only supported by the compiler of the last release (currently 2.4.2 although 2.4.0 works as well, but not 2.2.4 or older). It also used to be possible to compile FPC and its RTL with Turbo Pascal (the first FPC was produced this way) or using Delphi. But that time is long gone. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building compiler, rtl, host, target... (cross compiling)
- Original Message - From: "Hans-Peter Diettrich" To: "FPC developers' list" Sent: Thursday, 7 April, 2011 06:21 AM Subject: Re: [fpc-devel] Building compiler, rtl, host,target... (cross compiling) Skybuck Flying schrieb: So this is my biggest question and hunch: At some point during this whole step/phase the RTL needs to be switched/swapped with the new RTL... No swapping required. The host-RTL is linked *into* the compiler itself, the target-RTL is used (read, compiled) *by* the compiler, at runtime. Can you or anybody else give an example of the necessary command line parameters and/or a configuration file so I can try this out to see how it works ? (Please try to keep it as minimal as possible ;) :)) (For the example host could be windows/i386/x86 and target could be something ?) Bye, Skybuck. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] External assemblers (also modular discussion about free pascal compiler)
On 04/06/2011 10:46 PM, Skybuck Flying wrote: Is there perhaps some kind of "standardized intermediate form (data structure like)" which all compilers could choose to output ? (Which I am not aware off ?) gcc provides this. But in a discussion in this forum some time ago it has been found that the definition of the gcc structure of this information would need enhancement to be able to handle the Delphi-Pascal Object model. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ccharset.pas, charset.pas and strings/unicode ?
In our previous episode, Skybuck Flying said: > Suppose some kind of weird dissaster happens, like tsunami in japan... all > our computers are destroyed... (Then recompiling free pascal is the least of our problems) > What would happen if the compiler was unicode only ? > > Could the compiler still be build ? I would guess so... unless it depends on > some ansi strings in assembly or so... This is a very complicated situation, and such questions are not answerable, since everything depends on boundery problems. The easiest would probably be to go back in time and research when development systems migrated from local computer encodings to a standarised characterset (ansi). Since unicode mostly only increases the charset, it is less of a revolution than ansi was. > Furthermore what happens to statements/code like this: > > SomeString := 'SomeText'; > > I think in a unicode compiler 'SomeText' might actually be defaulted to > unicode ? Source code encoding and runtime encoding are two different things. In e.g. recent Delphis, the source code encoding (including such strings) is UTF8, while the runtime library encoding is UTF16. In general, your questions suffer from oversimplifications that make them unanswerable or not really a problem. As far as bootstrapping is concerned, such problems were very interesting in the seventies and eighties, and is considered mostly solved nowadays. The bootstrapping problem is a general problem for any compiler, not just freepascal. For some details of FPC's bootstrapping buildup have a look at the buildfaq: http://www.stack.nl/~marcov/buildfaq/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building compiler, rtl, host, target... (cross compiling)
On 04/06/2011 09:54 PM, Skybuck Flying wrote: First of all I would like to write that I failed to compile the RTL of Free Pascal so that might be adding a little bit too the confusion. AFAIK, not all versions of the compiler are tested to compile the compiler and the RTL. I have a separate (old) FPC installation to be able to always compile the latest svn versions. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building compiler, rtl, host, target... (cross compiling)
On 04/07/2011 03:06 AM, Skybuck Flying wrote: Missing from this list is ofcourse: debuggers/cross debuggers which would still be needed for serious platform development but that is beyond the scope of this posting ;) And unfortunately me very little to almost no experience with writing debuggers myself... perhaps a nice thing for me to explore in the future ;) Do you have a gdb for the new arch ? Same should be usable to debug FPC generated programs. AFAIK, someone has started a project doing a debugger in Pascal code, but I have no idea if this already works. Also one the native compiler (and command-line debugger) works, it should be possible to compile Lazarus for that arch. But why does it make sense to do the native development tools after all ? IMHO, usually, less effort and more desirable is to do a decent cross-compiling SDK: cross compiler, remote cross-debugger (needs only a "stub" on the target) and running Lazarus on a Windows or Linux PC. BTW, regarding the RTL: what OS-API does the arch provide ? some "open standard" like Linux Mono or Java, something more cryptic like the Windows or .NET API ore even something completely propriety ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel]Building compiler, rtl, host, target... (cross compiling)
On 04/06/2011 10:19 PM, Skybuck Flying wrote: 1. Why is it not possible for a single free pascal compiler executable to support and compile towards multiple targets ? (One target selected out of multiple target options) It does not make much sense to request this. It's no hassel at all to use different compiler executables and RTL files for different targets. And a multi-Target compiler would be slower, as at very may lines case-switches between the different target would need to be handled, and the much bigger compiler-executable would be less efficient regarding the CPU's cache use. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building compiler, rtl, host, target... (cross compiling) (terminology)
- Original Message - From: "Hans-Peter Diettrich" To: "FPC developers' list" Sent: Thursday, 7 April, 2011 06:10 AM Subject: Re: [fpc-devel] Building compiler, rtl, host,target... (cross compiling) Skybuck Flying schrieb: First of all "free pascal compiler" is not a "multi-target cross compiler" but it is a "dual-target cross compiler" (dual meaning host and target can be different ;)) FPC is a single target cross compiler. "cross" indicates that the target can be different from the host system. Perhaps you look at it from the binary level, but that's not fair, you should look at it from the source code level. Single refers to target. A zero-target cross compiler would be a cross compiler under development it has the framework to become a cross compiler but it does not yet have any supported targets. A single-target cross compiler is probably still a cross compiler under development but already has support for a single target. A dual-target cross compiler has support for two targets. A 6-target cross compiler has support for six targets. I would define a target as follows: Target = harware (cpu) + operating system (assembler + linker + rtl (so that application can hook into basic OS functionality)) To be able to cross compile from one target to another target actually requires two targets. It requires: 1. A host/local target 2. A guest/remote target (The source code of the compiler is compiled towards the host target, this requires some sort of host rtl.) (However the source code of the compiler also requires the source code of the guest target/rtl.) So in a way it needs support for both targets otherwise it will somehow not fully compile or it can't cross compile. And thus when I say a "dual target cross compiler" this would mean it has support in it's source code for two targets. The remaining question is: what is free pascal ? Free pascal I would describe as: a x-way self-hosting retarded (/brain-dead) (non-portable) cross compiler". (Perhaps I should even add internal assemblers etc but let's not for now). x should be replaced by the number of target-sub-folders. self-hosting refers to the fact that it can compile itself once it's build. retarded (/brain dead) refers to it's inability to switch targets during runtime. (only one guest-target seems to be selected during the compiler-self-build process). (non-portable) refers to it's inability of being compiled by other compilers. (For example Delphi can't compile the current state of the free pascal compiler source code) cross-compile refers to it's ability to cross compile to other targets. I hope I clearified that a little bit for you ! ;) =D Bye, Skybuck. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TFPHashList and FindIndexOf
After some debugging into a problem I was finding, I determined that
TFPHashList.FindIndexOf only works of the Key has non-nil data
associated with it. In other words:
list.Add('abcd', nil);
result := list.FindIndexOf('abcd');
In that case, result will be -1, because the InternalFind procedure
only returns a value "if assigned(Data)".
I think this is wrong behavior, or at least it's documented wrong. The
documentation says:
"FindIndexOf returns the index of the key AName, or -1 if the key does
not exist in the list. It uses the hash value to search for the key."
Well, the key DOES exist in the list... it's just associated with nil data.
Should I log a bug? Or is this really how it's supposed to work?
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
sethdgrover[at]gmail[dot]com
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building compiler, rtl, host, target... (cross compiling)
Advice : Google "Skybuck Flying troll". Notorious. Sent from my iPhone 4 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ccharset.pas, charset.pas and strings/unicode ? (>< symdif operator)
Hello,
As I was busy with the free pascal compiler source codes I came across an
unfamiliar operator for me: ><
(
It's in nflw.pas at line 830:
{Symdif operator, in case you are wondering:}
loopflags:=loopflags >< [lnf_checknegate];
)
First I googled it a bit and came across a language called: Fortress
http://labs.oracle.com/projects/plrg/Publications/fortress0866.pdf
I probably already came across it some time ago...
But this document does show how unicode could be used to introduce new
operators thanks to new unicode symbols...
Only problem is our keyboards might not yet be suited for it ? ;)
Thought I'd mention it in case you haven't seen it... but I'd bet you
probably seen it already ;) =D
Concerning the operator... I guess it unifies different sets and leaves out
the duplicates...
Bye,
Skybuck.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Oddity: Longint being converted automatically to int64 and then assignment/conversion operator used/applied for/to structure variable...(i386) branch (2.4.2)
Hello,
I am currently inspecting the following compiler unit of 2.4.2
branch/release ninl.pas:
line 1371: enum:=tenumsym(tenumdef(def).firstenum);
line 1372: v:=tenumdef(def).maxval;
Problem is with line 1372.
.maxval is apperently an integer.
v however only knows int64 implicit conversions (operators)
v is defined as
line 1352: v: tconstexprint;
tconstexprint is defined as in constexp.pas:
type Tconstexprint=record
overflow:boolean;
case signed:boolean of
false:
(uvalue:qword);
true:
(svalue:int64);
end;
With conversion operators:
operator := (const u:qword):Tconstexprint;inline;
operator := (const s:int64):Tconstexprint;inline;
operator := (const c:Tconstexprint):qword;
operator := (const c:Tconstexprint):int64;
operator := (const c:Tconstexprint):bestreal;
(Notice the missing conversion operators for integer/longint)
Therefore at least in theory it does not know how to convert an integer to
an int64.
Further proof that this is indeed what's happening:
tenumdef is defined as follows in symdef.pas:
line 563: tenumdef = class(tstoreddef)
minval,
maxval: aint;
aint is defined as follows in globtype.pas:
line 51:
{ Natural integer register type and size for the target machine }
{$ifdef cpu64bitalu}
AWord = qword;
AInt = Int64;
Const
AIntBits = 64;
{$endif cpu64bitalu}
{$ifdef cpu32bitalu}
AWord = longword;
AInt = longint;
Const
AIntBits = 32;
{$endif cpu32bitalu}
{$ifdef cpu16bitalu}
AWord = Word;
AInt = Smallint;
Assumption is that conditional cpu32bitalu is active (for i386)
Therefore Aint = longint;
So to me it seems a bit of an oddity... at least it's an integer which is
being tried to assign to an int64... so at least no overflow...
However v is a structure and .maxvalue is an integer...
So how come a conversion is being done ? (there is no conversion operator
for this situation ?)
So I am guessing free pascal does some conversion from integer to int64 and
then assign int64 to v ?
Isn't that a bit weird ? I guess it's kinda beautifull as well.. it
automatically detects a conversion path... however this is not what Delphi
XE would do...
so a slight deviation... causing me headaches... but I'll have to deal with
it...
Unless ofcourse you guys actually think it's a bug... then it's up to you to
fix it... but for now I will add some conversion operators to try and get it
working/compiling...
Bye,
Skybuck.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Oddity: Longint being converted automatically to int64 and then assignment/conversion operator used/applied for/to structure variable...(i386) branch (2.4.2)
Ok,
It seems wrong unit was being used... now I have corrected it and Delphi XE
seems to work as well... so no extra implicit conversion needed.
So I guess Delphi also automatically finds a conversion path...
Sorry for any confusion ;)
Bye,
Skybuck.
- Original Message -
From: "Skybuck Flying"
To: "Free Pascal Developers Mailing List"
Sent: Thursday, 7 April, 2011 08:01 AM
Subject: Oddity: Longint being converted automatically to int64 and then
assignment/conversion operator used/applied for/to structure
variable...(i386) branch (2.4.2)
Hello,
I am currently inspecting the following compiler unit of 2.4.2
branch/release ninl.pas:
line 1371: enum:=tenumsym(tenumdef(def).firstenum);
line 1372: v:=tenumdef(def).maxval;
Problem is with line 1372.
.maxval is apperently an integer.
v however only knows int64 implicit conversions (operators)
v is defined as
line 1352: v: tconstexprint;
tconstexprint is defined as in constexp.pas:
type Tconstexprint=record
overflow:boolean;
case signed:boolean of
false:
(uvalue:qword);
true:
(svalue:int64);
end;
With conversion operators:
operator := (const u:qword):Tconstexprint;inline;
operator := (const s:int64):Tconstexprint;inline;
operator := (const c:Tconstexprint):qword;
operator := (const c:Tconstexprint):int64;
operator := (const c:Tconstexprint):bestreal;
(Notice the missing conversion operators for integer/longint)
Therefore at least in theory it does not know how to convert an integer to
an int64.
Further proof that this is indeed what's happening:
tenumdef is defined as follows in symdef.pas:
line 563: tenumdef = class(tstoreddef)
minval,
maxval: aint;
aint is defined as follows in globtype.pas:
line 51:
{ Natural integer register type and size for the target machine }
{$ifdef cpu64bitalu}
AWord = qword;
AInt = Int64;
Const
AIntBits = 64;
{$endif cpu64bitalu}
{$ifdef cpu32bitalu}
AWord = longword;
AInt = longint;
Const
AIntBits = 32;
{$endif cpu32bitalu}
{$ifdef cpu16bitalu}
AWord = Word;
AInt = Smallint;
Assumption is that conditional cpu32bitalu is active (for i386)
Therefore Aint = longint;
So to me it seems a bit of an oddity... at least it's an integer which is
being tried to assign to an int64... so at least no overflow...
However v is a structure and .maxvalue is an integer...
So how come a conversion is being done ? (there is no conversion operator
for this situation ?)
So I am guessing free pascal does some conversion from integer to int64
and then assign int64 to v ?
Isn't that a bit weird ? I guess it's kinda beautifull as well.. it
automatically detects a conversion path... however this is not what Delphi
XE would do...
so a slight deviation... causing me headaches... but I'll have to deal
with it...
Unless ofcourse you guys actually think it's a bug... then it's up to you
to fix it... but for now I will add some conversion operators to try and
get it working/compiling...
Bye,
Skybuck.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Possibly bug spotted in scanner.pas
Am 07.04.2011 03:52, schrieb Skybuck Flying: > > The code typecasts this 9 byte record towards an 8 byte qword This wouldn't work and cause a compiler error. > and then > takes the first byte from that and type casts it to a char. The cast tconstexprint -> qword is overloaded. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FreeBSD 64bits SVN error
Hi, I'm trying to compile from trunk on a FreeBSD x86_64 box, and I'm getting this error: gmake clean all: ... thread.inc(411,10) Warning: Function result does not seem to be set /usr/home/martin/desarrollo/fpc/rtl/units/x86_64-freebsd/system.s: Assembler messages: /usr/home/martin/desarrollo/fpc/rtl/units/x86_64-freebsd/system.s:2262: Error: operand type mismatch for `movzbl' system.pp(349) Error: Error while assembling exitcode 1 system.pp(349) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted gmake[7]: *** [system.ppu] Error 1 gmake[7]: Leaving directory `/usr/home/martin/desarrollo/fpc/rtl/freebsd' gmake[6]: *** [freebsd_all] Error 2 gmake[6]: Leaving directory `/usr/home/martin/desarrollo/fpc/rtl' gmake[5]: *** [rtl] Error 2 gmake[5]: Leaving directory `/usr/home/martin/desarrollo/fpc/compiler' gmake[4]: *** [next] Error 2 gmake[4]: Leaving directory `/usr/home/martin/desarrollo/fpc/compiler' gmake[3]: *** [ppc1] Error 2 gmake[3]: Leaving directory `/usr/home/martin/desarrollo/fpc/compiler' gmake[2]: *** [cycle] Error 2 gmake[2]: Leaving directory `/usr/home/martin/desarrollo/fpc/compiler' gmake[1]: *** [compiler_cycle] Error 2 gmake[1]: Leaving directory `/usr/home/martin/desarrollo/fpc' gmake: *** [build-stamp.x86_64-freebsd] Error 2 My FPC version is this: Free Pascal Compiler version 2.5.1 [2011/03/29] for x86_64 Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] "helper" feature finished
Am 06.04.2011 13:35, schrieb Florian Klaempfl: Am 05.04.2011 17:34, schrieb Sven Barth: Am 05.04.2011 17:06, schrieb Florian Klaempfl: Am 05.04.2011 04:27, schrieb Paul Ishenin: I think your branch should be reviewed either by Florian I did a quick review and found nothing important, only a few remarks: - current_syssym: is it really needed? Can't the type checking be done during the type check pass? If it's needed, it should be reset to 0 somewhere during parser initialization because in case of a fatal error when the compiler is compiled into an ide, at the next start current_syssym would have a wrong value. The problem is that basically all references to class helpers are forbidden except inside of SizeOf and TypeInfo (and BitSizeOf). Thus when one of those symbols is encountered the checks against the use of a class helper type reference are already "active". So the only way out I have found was the introduction of that current_syssym variable to check whether I'm currently inside one of those three functions. If you have an idea how to solve this with by using the type check pass I'll be glad to do so. Just let me ask different: what code compiles, if the check is not here? The expressions accepting a type node but not a class helper should be easily fixable. I've now looked at that again and I still don't see a possibility to "drop" current_syssym again (of course I don't know whether I've looked at the correct locations and understood everything correctly...). You basically suggest to extend ttypenode.typecheck_pass to check for a class helper, correct? If so then the problem is that I can't check whether I'm inside one of the three allowed syssyms as no node is generated for them (yet). Also typecheck_pass is already called inside comp_expr (by postfixoperators) so I can't even say to simply not do do_typecheckpass_changed. So if I haven't misunderstood the concept somewhere (point 1) or you haven't got a better/correct solution (point 2) then I'm afraid that current_syssym needs to stay (of course with a proper initialization ^^). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
