[fpc-devel] ccharset.pas, charset.pas and strings/unicode ?
Hello,
I am having momentarily confusion about the situation with ccharset.pas and
charset.pas and strings, ansistrings and unicode in general... ?!?
So some questions about this:
I in particularly do not understand the following uses clausule:
{$ifdef VER2_2}ccharset{$else VER2_2}charset{$endif VER2_2},
Somewhere it says something about bootstrapping and stuff like that... it
seems to have something to do with unicode mappings...
It also said that this wasn't necessary anymore beyond version 2.2.2 or
something ?
This seems to me like a little unicode-hack to get unicode into the compiler
or something ?
What the hell is this ? =D
Anyway some questions about the free pascal 2.4.2 sources in relation to
Delphi XE situation:
In the latest Delphi versions string is now considered a Unicode string.
What's the situation with the options.pas in the compiler folder ?
Lot's of string stuff and character stuff going on there... ansistring
versus unicodestring, ansichar versus unicodechar ?
Seems a bit conflicting for what I am trying to do... which is use some of
this code in Delphi...
So I am getting all kinds of typecast/implicit string cast warnings and
errors and stuff and potential data loss
from string to ansistring... a bit too whacky for my taste but ok...
So to get some sense into all of this let me ask you a simple question:
1. What type of strings does free pascal use ? Especially in options.pas ?
Are these string types considered to be AnsiStrings or UnicodeStrings ???
And what about char types ? Are those AnsiChar or UnicodeChar ???
(probably also know as widechar,widestrong...)
(I have in principle done no real programming yet with the newer Delphi
versions with the unicode stuff in it...
so this is new stuff for me... and now a bit confusion unfortunately... and
perhaps even unavoidable confusion...
because this reinterpretation that new-borland did is now conflicting
and causing interpretation issue's :(
so it depends on the compiler... and I don't know what free pascal does...
so that's why I ask here...)
Also there is something I don't understand about the conditional way above:
It reads in away:
IF VERSION IS 2.2 THEN USE CCHARSET ELSE CHARSET
The thing is: I am using 2.4.2 and CHARSET is missing from 2.4.2
So perhaps this conditional was ment to read something like:
if Version 2.2 then use CCHARSET else CHARSET; ???
So for 2.4.2 I must probably use CCHARSET.pas the thing with the confusing
strings remains though ;)
So for messy posting... but this is messy ! ;) =D
Bye,
Skybuck.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a redcode assembler to Free Pascal Compiler
On 04/05/2011 04:21 PM, Hans-Peter Diettrich wrote: Of course every platform needs a RTL, at least for memory allocation, basic I/O and probably for file handling. Thread handling (e.g. threadvars) is another example. Using libc (in Linux) prevents doing ASM or arch depending code in the RTL. This has pros and cons which already have been discussed here several times. -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 ?
On 04/06/2011 08:30 AM, Skybuck Flying wrote: In the latest Delphi versions string is now considered a Unicode string. The realization of something like this is done in a dedicated new string branch of the svn called cpstrnew. AFAIK, it's still far from usable. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changes in Makefile-system
02.04.2011 1:15, Joost van der Sluis пишет: Hi all, I've just committed a change in the Makefiles for the fcl-web package. The Makefile now calls fpmake to build and install the package. Another disaster occurs when I try to use the same source tree from different OSes. Say first I build in Linux, it successfully creates the '/packages/fcl-web/fpmake' executable. After that building from Windows fails since it attempts to run the Linux fpmake without rebuilding it. `make clean' from Windows does not remove Linux executable (tries to remove the 'fpmake.exe' or does not remove it at all, or maybe for some other reason). Removing it by hand solves the problem. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changes in Makefile-system
On Wed, 2011-04-06 at 12:28 +0400, Sergei Gorelkin wrote: 02.04.2011 1:15, Joost van der Sluis пишет: Hi all, I've just committed a change in the Makefiles for the fcl-web package. The Makefile now calls fpmake to build and install the package. Another disaster occurs when I try to use the same source tree from different OSes. Say first I build in Linux, it successfully creates the '/packages/fcl-web/fpmake' executable. After that building from Windows fails since it attempts to run the Linux fpmake without rebuilding it. `make clean' from Windows does not remove Linux executable (tries to remove the 'fpmake.exe' or does not remove it at all, or maybe for some other reason). Removing it by hand solves the problem. The reason that fpmake is not removed, is that you need it to do the clean. But maybe I can let the akefile compile fpmake, then run it to do the cleanup, and then remove the executable again. To solve your actual problem, we could add a suffix to the fpmake executable name in case it is build by the Makefile. fppkg can simply check if the existing executable does work, and if not, re-compile it. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] helper feature finished
06.04.2011 2:20, Sven Barth пишет: On 05.04.2011 17:34, Sven Barth wrote: - Is ibsymtableoptions needed? Couldn't be the value just be written to the ppu without a new entry? It didn't work the first time I added that, but it might be because of other errors I had at that time. I'll recheck that to be sure. I now remember why I did it... PPUs are entry based and symtables (tstoreddef) don't have a PPU entry for themselves. They only write two entries: one for the defs and one for the symbols. So if I wouldn't have introduced a new entry for the options I would have broken all read operations when they'd read that new PPU or I would have needed to add the value to either the symbol entry or the def entry (both solutions are rather unclean). And what will happen if you write options before defs and symbols? Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changes in Makefile-system
On Sun, 2011-04-03 at 03:51 +0400, Sergei Gorelkin wrote: On 02.04.2011 01:15, Joost van der Sluis wrote: Hi all, I've just committed a change in the Makefiles for the fcl-web package. The Makefile now calls fpmake to build and install the package. I'm unable to run the test suite with this change, apparently it tries to install package files to their permanent location (/usr/local/lib/fpc/2.5.1/units/...), while the test suite uses a temporary location under 'tests' directory. Following is a fragment of log showing a correctly processed package (fv) and the error: This should be solved in r17261. Can you confirm that? Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changes in Makefile-system
06.04.2011 12:56, Joost van der Sluis пишет: Another disaster occurs when I try to use the same source tree from different OSes. Say first I build in Linux, it successfully creates the '/packages/fcl-web/fpmake' executable. After that building from Windows fails since it attempts to run the Linux fpmake without rebuilding it. `make clean' from Windows does not remove Linux executable (tries to remove the 'fpmake.exe' or does not remove it at all, or maybe for some other reason). Removing it by hand solves the problem. The reason that fpmake is not removed, is that you need it to do the clean. But maybe I can let the akefile compile fpmake, then run it to do the cleanup, and then remove the executable again. I was seeing it from the point one system does not touch files created by/for the other system, to be honest. The things are going to get even more interesting when cross-compilation comes in... To solve your actual problem, we could add a suffix to the fpmake executable name in case it is build by the Makefile. fppkg can simply check if the existing executable does work, and if not, re-compile it. ...it will end up with a directory containing (hosts * targets) fpmake executables? Just-in-time recompilation looks somewhat better in comparison with that :) Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Recent changes to TField.SetData
Small optimalization use dsWriteModes instead of fixed set: - if not (State in [dsEdit, dsInsert, dsFilter, dsCalcFields]) then //here should be IMO also dsNewValue + if not (FDataSet.State in dsWriteModes) then DatabaseErrorFmt(SNotEditing,[FDataSet.Name],FDataSet); if ReadOnly and (FieldNo0) and not (FDataSet.State in [dsSetKey, dsFilter]) then DatabaseErrorFmt(SReadOnlyField, [DisplayName], Self); 829 FDataSet.SetFieldData(Self,Buffer, NativeFormat); -- Laco. ___ 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. If I remember correctly (and my comment at the location is correct which I hope it is ^^) the case should be the following: TMyHelperType.SomeClassMethod; But I'll recheck that later to be sure. Regards, Sven ___ 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 ?
Am 06.04.2011 08:30, schrieb Skybuck Flying:
Hello,
I am having momentarily confusion about the situation with ccharset.pas
and charset.pas and strings, ansistrings and unicode in general... ?!?
So some questions about this:
I in particularly do not understand the following uses clausule:
{$ifdef VER2_2}ccharset{$else VER2_2}charset{$endif VER2_2},
Somewhere it says something about bootstrapping and stuff like that...
it seems to have something to do with unicode mappings...
It also said that this wasn't necessary anymore beyond version 2.2.2 or
something ?
Something like this is normally done when code is added to the RTL (in
this case the unit charset) which is used by the compiler as well. As
the compiler must be built with an older compiler (and its older RTL)
first, that compiler does not yet know about the charset unit. Thatfor
the unit is copied to the compiler's directory with a c prefix (in
this case ccharset) until a release is made which contains that new
unit. The unit you are looking for is in rtl/inc now, so that
ifdef-construct (and the ccharset unit) could be removed now.
Something similar was done a few days ago with the new windirs unit
which was added as cwindirs to the compiler as well.
This seems to me like a little unicode-hack to get unicode into the
compiler or something ?
What the hell is this ? =D
Anyway some questions about the free pascal 2.4.2 sources in relation to
Delphi XE situation:
In the latest Delphi versions string is now considered a Unicode string.
What's the situation with the options.pas in the compiler folder ?
Lot's of string stuff and character stuff going on there... ansistring
versus unicodestring, ansichar versus unicodechar ?
Options.pas has nothing to do with different string types. It's for
parsing the command line arguments and the configuration file and for
setting up the start defines based on that arguments and files. Mostly
you don't need to touch options.pas at all.
Seems a bit conflicting for what I am trying to do... which is use some
of this code in Delphi...
So I am getting all kinds of typecast/implicit string cast warnings and
errors and stuff and potential data loss
from string to ansistring... a bit too whacky for my taste but ok...
So to get some sense into all of this let me ask you a simple question:
1. What type of strings does free pascal use ? Especially in options.pas ?
Are these string types considered to be AnsiStrings or UnicodeStrings ???
And what about char types ? Are those AnsiChar or UnicodeChar ???
(probably also know as widechar,widestrong...)
The compiler itself mostly uses ShortString and pointers to ShortString
as they don't have the reference counting and thus are faster to handle.
In some seldom cases AnsiString (aka String) is used and WideString is -
as far as I'm aware of - never used.
The supported string types by FPC though are ShortString, AnsiString,
WideString (non reference counted 2 Byte String for Windows
compatibilty) and UnicodeString (reference counted 2 Byte String). On
all platforms except Windows (Win32, Win64, WinCE) a WideString is an
alias for UnicodeString.
In mode Delphi String is an alias for AnsiString in all other modes
(unless $H+ is given) String is an alias for ShortString.
(I have in principle done no real programming yet with the newer Delphi
versions with the unicode stuff in it...
so this is new stuff for me... and now a bit confusion unfortunately...
and perhaps even unavoidable confusion...
because this reinterpretation that new-borland did is now
conflicting and causing interpretation issue's :(
so it depends on the compiler... and I don't know what free pascal
does... so that's why I ask here...)
Also there is something I don't understand about the conditional way above:
It reads in away:
IF VERSION IS 2.2 THEN USE CCHARSET ELSE CHARSET
The thing is: I am using 2.4.2 and CHARSET is missing from 2.4.2
This condition is the correct one. CCharSet should be removed maybe as
all compilers from 2.4.0 on use CharSet from the RTL directory.
So perhaps this conditional was ment to read something like:
if Version 2.2 then use CCHARSET else CHARSET; ???
So for 2.4.2 I must probably use CCHARSET.pas the thing with the
confusing strings remains though ;)
So for messy posting... but this is messy ! ;) =D
No, it's not ;)
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler subfolders: i386, x86
Skybuck Flying schrieb: I have a little question about these subfolders in the compiler folder, they are called: 'i386' and 'x86' What are these folders, they seem samiliar ? The x86 targets are splitted into 4 directories, AFAIR i386 for 32 bit, ia64 for Intel IA-64 architecture (discontinued), x86_64 for AMD 64 bit (now also Intel 64), x86 contains common parts for all above (perhaps also relicts from 16 bit?) DoDi ___ 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)
Wow, wow, wow... you are indeed a bit confused here. On 06.04.2011 21:54, Skybuck Flying wrote: Hello, 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. (Just simple i386/x86 tests to see if the sources build) The compiler however seems to compile fine. I am now a bit confused about the whole theory of things and I will try to explain my confusion: The confusion pretty much starts with the compiler needing some RTL includes and units and especially some types like DWORD or PtrInt to be able to compile itself ?!? This is a little bit weird to me: Why would the compiler need an RTL to compile itself ? (Perhaps these are accidental, or unnecessary depedancy ?) RTL is an abbreviation for Runtime Type Library and it's necessary for EVERY Free Pascal program, because it abstracts the functions of the operating system, provides the system unit and types and other units. As the compiler is just a plain Free Pascal program itself (and when FPC compiles itself it just compiles a plain FPC program) it's absolutely naturaly that the compiler needs the RTL. I would have been more surprised if the compiler would not need the RTL... I am now a bit confused again about what free pascal is... As far as I can remember I once build a free pascal compiler which would compile from a certain host operating system towards another target operating system. Is free pascal supposed to be able to do this all naturally by itself (as long as it can use external tools) ? Yes. As free pascal is able to cross compile (see below). I just consulted my little tutorial on building a free pascal cross compiler which I once wrote and I notice the following things: It mentions a cross assembler and a cross linker these where external GNU related tools. From the looks of it I'm thinking right now that Free Pascal might actually not be a cross compiler and it actually can only compile to it's own platform that the compiler executable was compiled for. This assumption is wrong. The following assumption is right: the compile can only compile for the one target it was configured for. The target the compiler is compiled to and the target the compiler compiles for don't need to be the same. E.g. I could compile a PowerPC cross compiler by compiling an ARM based compiler that is cross compiled by a i386 cross compiler for ARM. So in other words if this hypothesis above is correct then what was happening at the time might have been the following situation: 1. Free Pascal (fake cross) compiler compiles the source from PPC386.EXE (i386 host) towards Linux/PowerPC (made up target) as x86 assembly. 2. The cross-assembler.exe from GNU tools takes the x86 assembly produced by free pascal compiler and actually cross-assembles it for linux/powerpc into powerpc assembly. 3. The cross-linker does the rest. Let's assume you want a native ARM compiler and start with an i386 compiler then the steps are like this: 1. compile a i386=ARM cross compiler by compiling pp.pas using the correct defines 2. compile the RTL for ARM using the new cross compiler 3. compile a ARM=ARM compiler by compiling pp.pas using the correct defines and by using the i386=ARM compiler and the ARM RTL = tada! you have a native ARM compiler (and a i386 = ARM compiler as well) [of course this assumes that you have binutils and eventually needed libraries to do the cross compile] So suppose that's how it was working at the time then Free Pascal is actually not really a cross compiler. You are supposing wrong ;) However this does not mean it's useless for my project/experiments... I need Free Pascal to be a cross compiler which compiles to abstract assembly so I can assemble it further into any assembler a true cross compiler I would say ;) Perhaps I am wrong and you guys would like to correct me... but for that I will help you by asking a question: 1. Would it be possible to build the following compiler: FreePascalCompiler.exe (runs on windows) (compiles for virtual machine instructions/outputs virtual machine assembly). Yes this would be possible. Does that virtual machine you want to target FPC for provide its own virtual instruction set or does it use the instruction set of one of the already supported platforms? If the latter then you don't need to do much. If the first then you either need to find cross binutils that allow you to assemble code to that virtual instruction set or you must write an internal assembler for FPC. In both cases though you must add a new cpu (parallel to ARM, i386, PowerPC, etc.) that contains the needed methods for the compiler to call (that generate the assembler code for the assembler) and handles calling conventions, variable locations, etc. Or is a FreePascalCompiler.exe (x86) only capable of producing x86 assembly like I suspect it might be/do... Suppose I am correct and free pascal
Re: [fpc-devel]Building compiler, rtl, host, target... (cross compiling)
Hi, maybe some basic info could help you understand some things: http://wiki.lazarus.freepascal.org/Cross_compiling Regards Žilvinas On 2011-04-06 23:19, Skybuck Flying wrote: Hello, ... Bye, Skybuck. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] External assemblers (also modular discussion about free pascal compiler)
Hello, Perhaps some last silly questions about external assemblers. First I'd like to say that I saw some tutorial where the compiler itself produced some form of assembly output in text... probably real assembly... So that's kinda interesting to output text this makes it flexible for other tools to then compile that... It reduces complexity of the compiler because it doesn't actually need to fully assembly the assembly... this can be left to other tools. So far I understand free pascal has internal assemblers (probably mostly for i386/x86 target, does it have others as well ?) But there is also this external assembler thingy perhaps it's being used to implement internal assemblers as well... But my question is the following: What exactly is being fed towards the external assembler via the classes/api ? (I probably should take a closer look... ) But from what I can remember I saw some kind of node structure... (maybe fp list/node and stuff like that ?) To me it seemed like some kind of free pascal classes/data structures which might not be commonly supported by other languages like C/C++/Delphi/Etc... So just in case I am wrong I am asking the following question: 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 ?) (Or is the external assembler thingy indeed something conceived by the pascal developers themselfes ;)) Also one last question: Is there actually any other external tool which is actually invoked/call via this mechanism ? (If the mechanism was ment to function via text then I can imagine that ofcourse... but then the question would be: what kind of text would be fed ? (some early form of assembly which needs to be fixed up ? ) Sending assembly towards an assembler seems kind weird... because first the compiler seems to use these nodes/data structures which are then apperently send towards some kind of cpu which seems to use assembly like data structures as well (but I could be wrong) which would then be turned back into text (Why then not compile directly to binary ??? Perhaps because the binaries involve operating system specific structures and the CPU can actually be used for different operating systems ? (So I think that's probably the answer here...) The compiler compiles towards a certain CPU and makes sure the assembly is suited for the CPU... but it doesn't necessarily want to know about the operating system and thus sends it off to an operating system specific assembler ?) (But then again this conflicts a bit with the RTL which does seem a bit operating system aware... but maybe that is not related to this and the RTL is ment for input towards the compiler and perhaps output as welll but in a more file like manner...) A guess what I described above is the roll of the linker The linker links the assemblies and adds some operating system specific binary headers/structures for towards/for the final binary. Does free pascal actually have an internal linker as well ? Perhaps all these different aspects of a compiler are confusing things a little bit for me/noobies but perhaps also for the developers itself... Therefore I wonder if free pascal could benefit from a more modular approach where everything is nicely split up into modules... which somehow communicate with each other... This could be executables (though would get a bit difficult via files) or (dll's but that's windows specific) or (sockets... network communications seem odd for this...) and finally simply compiled units which would be placed in seperated module folders or so. (with the necessary headers... could also simply include full source as well). Currently I wonder how modular free pascal is... since I am not acquinted with the code (yet)... from the looks of it it seems to use classes here and there... so at least it's class-modular but classes can also starts to mingle with each other a bit... and might not form a clean cut. Probably tempting for developers to mingle stuff up a bit... None-the-less that's probably easily avoidable or fixeable... The problem remains that all source code is in pretty much one huge folder called: compiler with some sub folders for platforms. At least the platforms are seperated from it... but this seems also a bit out of necessity for the search paths to not produce naming-space-conflicts and such. The rest of the compiler code seems to be in one huge folder... Some of the unit names are pretty short and not very descriptive... fortunately most of the unit files have a little comment in the header explaining what each file is. Perhaps it would be interesting to try and split up the compiler folder into subfolders where each subfolder would represent a module. For example tokenizer/lexer, parser, assemblers and what else you can think of which
Re: [fpc-devel] External assemblers (also modular discussion about free pascal compiler)
On 06.04.2011 22:46, Skybuck Flying wrote: Hello, Perhaps some last silly questions about external assemblers. First I'd like to say that I saw some tutorial where the compiler itself produced some form of assembly output in text... probably real assembly... So that's kinda interesting to output text this makes it flexible for other tools to then compile that... It reduces complexity of the compiler because it doesn't actually need to fully assembly the assembly... this can be left to other tools. So far I understand free pascal has internal assemblers (probably mostly for i386/x86 target, does it have others as well ?) Only i386 and x86_64 as far as I'm aware of. But there is also this external assembler thingy perhaps it's being used to implement internal assemblers as well... But my question is the following: What exactly is being fed towards the external assembler via the classes/api ? Files containing assembler code for the selected target (because a (external) assembler just takes that file as if someone would have written it by hand and assembles that to the correct opcodes and operands (simply spoken). (I probably should take a closer look... ) But from what I can remember I saw some kind of node structure... (maybe fp list/node and stuff like that ?) This is bascially the abstract syntax tree and only used internally. To me it seemed like some kind of free pascal classes/data structures which might not be commonly supported by other languages like C/C++/Delphi/Etc... So just in case I am wrong I am asking the following question: 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 ?) No, there isn't. (Or is the external assembler thingy indeed something conceived by the pascal developers themselfes ;)) Every external assembler understands the assembly language that it can assemble code for. An i386 assembler understands i386 assembler instructions while it does not understand ARM ones and the other way round. So the compiler outputs the code that the assembler expects. Also one last question: Is there actually any other external tool which is actually invoked/call via this mechanism ? No by the exact same mechanism, but there is also the resource compiler (fpcres) and the linker (seldom used on Windows targets as those have a internal linker (netware now as well as it seems...)). (If the mechanism was ment to function via text then I can imagine that ofcourse... but then the question would be: what kind of text would be fed ? (some early form of assembly which needs to be fixed up ? ) No. The optimized assembler code that should be assembled by the assembler into the final object code. Sending assembly towards an assembler seems kind weird... because first the compiler seems to use these nodes/data structures which are then apperently send towards some kind of cpu which seems to use assembly like data structures as well (but I could be wrong) which would then be turned back into text Why is it weird when the external tool (which is not developed by the FPC developers but by others, e.g. the GNU devs) does only understand that text? (Why then not compile directly to binary ??? Perhaps because the binaries involve operating system specific structures and the CPU can actually be used for different operating systems ? (So I think that's probably the answer here...) The compiler compiles towards a certain CPU and makes sure the assembly is suited for the CPU... but it doesn't necessarily want to know about the operating system and thus sends it off to an operating system specific assembler ?) The operating system isn't that important. But the compiler does not know by itself that mov is that or that opcode. So it needs an assembler to produce the final object code. And sometimes such an assembler is available in the compiler itself as well, so one doesn't need to rely on an external tool... (But then again this conflicts a bit with the RTL which does seem a bit operating system aware... but maybe that is not related to this and the RTL is ment for input towards the compiler and perhaps output as welll but in a more file like manner...) A guess what I described above is the roll of the linker The linker links the assemblies and adds some operating system specific binary headers/structures for towards/for the final binary. No. The linker just puts the generated object files together and adds the needed headers for the final binary (PE or ELF header) so that the operating system can load and run the executable or binary. All the operating system specific functions are already resolved and added by FPC itself. Does free pascal actually have an internal linker as well ? Yes. It contains a PE linker, an (unfinished?, experimental?) ELF linker, an unfinished linker for OS/2 and since some days
[fpc-devel] Possibly bug spotted in scanner.pas
Around line 1120: else if is_char(constdef) then begin read_factor:=char(qword(value.valueord)); factorType:= [ctetString]; end valueord seems to be type casted towards an int64. The actual field is defined as follows in symsym.pas: tconstvalue = record case integer of 0: (valueord : tconstexprint); 1: (valueordptr : tconstptruint); 2: (valueptr : pointer; len : longint); end; valueord is defined as follows in constexp.pas: type Tconstexprint=record overflow:boolean; case signed:boolean of false: (uvalue:qword); true: (svalue:int64); end; In other words the last record is 9 bytes, the first byte is actually an overflow byte. The code typecasts this 9 byte record towards an 8 byte qword and then takes the first byte from that and type casts it to a char. (Which will probably be unsafe if char is changed to wide char or perhaps not... time will tell) So to me it seems the overflow boolean is being assigned towards the read_factor variable. If that was the intent then it's probably ok... but else it might be a bug ? If that was the intent then why not write: read_factor := char(value.valueord.overflow) Also my assumption that a boolean is only 1 byte might be wrong ;) but for now I will assume it's 1 byte ;) To me the code looks a bit suspicious but it might be nothing... Bye, Skybuck. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a new assembler to Free Pascal Compiler
Hello, (This posting/reply is mostly ment for: Hans-Peter Diettrich) I saw you mentioned you are working on the front end part of the compiler. I also saw you want to introduce either syntaxes or perhaps even languages (?) I guess you want to experiment with alternative syntaxes or introduce other languages, correct (?) Could ofcourse also be learning experience for you... But where are your primary goals ? ;) I can imagine alternative syntaxes... I can also understand the wish to perhaps introduce C syntax or C++ syntax... perhaps for the speed of the compiler ? You also seem to want to make the front end more flexible... I can understand that in a way ;) But why exactly ? Perhaps you can shed some more light on what kind of language experimentation or other languages you had in mind ? Currently I see that the free pascal compiler was not written in purely turbo/borland/delphi/oo pascal... instead it uses some new language/syntaxes here and there... which will probably cause some transpiration/headaches down the line/in the near future... So seeing these little problems I am not so sure if I like your kind of experimentation ! LOL. But then again parallel language extensions or perhaps cuda/ptx language extensions in the future might be interesting. One thing I haven't mentioned so far is even support for opengl and nvidia cg, pascal shading languages. I would also be a little bit interested in a pascal compiler which could compile to a shading language. Perhaps some of your front-end work might come in handy to introduce new pascal language syntax specially tailored for shading language... which could then be enabled or disabled in project settings or even better compiler-understand conditionals/directives that would be real nice... Bye, Skybuck. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a new assembler to Free Pascal Compiler (language features supported/not supported options)
Here is one little idea which might be obvious: 1. The assembler could notify to the rest of the system like parser or symantic checker which languages features are supported and which are not supported by the assembler. This way certain language elements of the language could be turned off. This might be helpfull to introduce pascal to new hardware which might not support certain things like pointers or virtual pointer/method tables/whatever or calls or integer support or floating point support. So each element of the pascal language could get a boolean supported/not supported so that an assembler can cherry-pick what it wants to support at first... then later it can start supporting other elements. The benefit of this is that the symantic checker or parser can throw warnings/errors into the face of the user to notify him/her that he/she is using non-supported language features and such re-consider for the time being ;) 2. It would/could also be beneficial to the user... if the user simply doesn't want to use certain new language features and wants to make absolutely sure that they are not accidently being used then he/she could also disable certain language features and have the compiler automatically check if the user source code is complieing towards the settings/language element rules. This could be helpfull in later porting/re-writing the code to other languages and/or systems. For example: first developing software on PC/CPU and later porting it to PC/GPU/Shaders/CG/OpenCL/PTX or anything new that comes along ;) =D 3. It might even be helpfull to disable buggy language features or types and quickly diagnose source code to see if it contains non-allowed language features/types. 4. Last but not least, handy new languages features could be turned on and be used ;) :) =D Bye, Skybuck. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a new assembler to Free Pascal Compiler
Skybuck Flying schrieb: (This posting/reply is mostly ment for: Hans-Peter Diettrich) I saw you mentioned you are working on the front end part of the compiler. I also saw you want to introduce either syntaxes or perhaps even languages (?) Both, but this project is OT here. Have a look at my SourceForce project FpcExt... DoDi ___ 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)
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. 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 No. First the RTL is compiled, then the compiler is built with that RTL. The compiler is a little bit like an application, applications need a system unit, the runtime library provides that system unit. That's why the RTL is compiled before. The compiler is built *exactly* like any other application, in this step. In the next step the new compiler is used to compile itself. This way new features can be included, which the old (bootstrap) compiler could not compile (e.g. class helpers...). This step is repeated until the last two executables are binary identical. This procedure allows for further extensions, that even could not be compiled by an earlier stage compiler, without the need to specify an exact number of required recompilations. 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) ... and which can compile the new language version, including all added features. 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. Right. Every application must use the RTL of its host platform. 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? Every compiler can compile the RTL for its target, as well as other applications. Apperently specifieing the NewRTL can be done by compiler command line options or configuration files. As is, the specification of the target (hard coded in the compiler) is sufficient to locate target-specific parts of the source code, in target-specific directories. I really like that idea :-) 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. Every target e.g. has its own data types, like 32 or 64 bit pointers. That's why the compiler has to use the target-specific version of the RTL, in cross-compiling any code. So perhaps it's the internal linker which needs the NewRTL to be present to do it's work ?!? How else could it work ?? Every linker needs binaries that have been compiled for the target, and includes them into the final executable (for the same target). 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. That's fully automatic. The compiler compiles or loads precompiled units recursively, by evaluating the Uses clauses, so that it traverses the target specific RTL and ends up in the System unit. All parts of the target, that are required for a compilation, are already built into the compiler. That includes code generation for the target CPU, and linking executables for the target OS (what may actually occur in an external assembler and linker). 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. 2. Step 2 (building free pascal compiler) Build the free pascal compiler with the external pascal compiler. This
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. DoDi ___ 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 ?
Hmm ok, so here is a little theoretical/hypothetical question for you to
think and guess about ;):
Suppose some kind of weird dissaster happens, like tsunami in japan... all
our computers are destroyed...
What remains are the free pascal source codes.
What remains is a object pascal compiler which works with unicode strings
only.
Now suppose string is defined as a unicode string.
This would lead to some problems... but ok... if the compiler supports
shortstring then that's easily solved...
But my question is a little bit the following:
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...
Furthermore what happens to statements/code like this:
SomeString := 'SomeText';
I think in a unicode compiler 'SomeText' might actually be defaulted to
unicode ?
So then perhaps in compiler it's necessary to typecast this explicitly to:
SomeString := AnsiString('SomeText');
or perhaps even
SomeString := ShortString('SomeText');
I am not sure if these typecasts are needed or if there is a better way...
One way would be:
ShortString := 'SomeText';
But then the assumption would be that the compiler turns the string into
whatever ShortString is...
But then the question is what would the following do:
if SomeString = 'SomeText' then
???
Would 'SomeText' be used to have the same type as SomeString ?
Would automatic conversion take place ?
or
Would a string type violation occur if the SomeString was of another type
then the default of 'SomeText'... ?
So that's pretty nasty...
At the moment I have little idea what Delphi XE does... (little experience
with unicode)
But I would guess everything defaults to unicode ?!? I could be wrong
though...
(At least that's what it seems to be doing ;))
That does not necessarily mean I agree with how things are done in Delphi XE
but such is life ;)
Anyway what remains to be discussed is advantages of a unicode compiler...
One thing comes to mind: chinese people and greek people might be able to
develop a compiler in their own language...
Also what remains is disadventages of unicode compiler...
You already mentioned possible performance issue's... though is there really
that much difference between shortstring and widestring and ansistring...
it's more or less the same except one has a reference count and another has
double the ammount of characters...
But a bigger disadventage which I can imagine is operating systems...
perhaps older ones which do not support unicode ?!?
What would happen to them ?!? Big string corruption me thinks ;) But I could
be wrong ;)
Maybe even free pascal dos applications could still somehow use unicode if
the compiler took care of all of it ?
At least internally in the application it would then work... same could be
done for win95...
Only communication with api's in win95 or interrupts in dos would probably
screwed up... relating to dos those pretty little might be re-written but
ok.
Must draw the line somewhere... perhaps even unicode-fonts could be included
;) pff ;) (but that's probably pushing it ! ;) =D) Nice to think of
possibilities though... I like backwards compatibility quite a lot ;)
Bye,
Skybuck =D
- Original Message -
From: Sven Barth pascaldra...@googlemail.com
To: fpc-devel@lists.freepascal.org
Sent: Wednesday, 6 April, 2011 14:40 PM
Subject: Re: [fpc-devel] ccharset.pas, charset.pas and strings/unicode ?
Am 06.04.2011 08:30, schrieb Skybuck Flying:
Hello,
I am having momentarily confusion about the situation with ccharset.pas
and charset.pas and strings, ansistrings and unicode in general... ?!?
So some questions about this:
I in particularly do not understand the following uses clausule:
{$ifdef VER2_2}ccharset{$else VER2_2}charset{$endif VER2_2},
Somewhere it says something about bootstrapping and stuff like that...
it seems to have something to do with unicode mappings...
It also said that this wasn't necessary anymore beyond version 2.2.2 or
something ?
Something like this is normally done when code is added to the RTL (in
this case the unit charset) which is used by the compiler as well. As
the compiler must be built with an older compiler (and its older RTL)
first, that compiler does not yet know about the charset unit. Thatfor
the unit is copied to the compiler's directory with a c prefix (in this
case ccharset) until a release is made which contains that new unit. The
unit you are looking for is in rtl/inc now, so that ifdef-construct (and
the ccharset unit) could be removed now.
Something similar was done a few days ago with the new windirs unit
which was added as cwindirs to the compiler as well.
This seems to me like a little unicode-hack to get unicode into the
compiler or something ?
What the hell is this ? =D
Anyway some questions about the free pascal 2.4.2 sources in relation to
Delphi XE
