Re: [fpc-pascal] Free Pascal Support for ARM Architecture
On 08 Dec 2008, at 00:33, Prince Riley wrote: On Sun, Dec 7, 2008 at 4:53 PM, Jonas Maebe [EMAIL PROTECTED]wrote: On 07 Dec 2008, at 23:01, Prince Riley wrote: FPC does not specify any particular sub-architecture to the assembler. was not an opinion or a guess, but a fact. What sub-architecture the GNU assembler picks in that case (i.e., by default) was the guess. My point is saying 'guess' was not to discredit your statement about what the FP compiler does, rather to say that no one seems to know exactly what ARM option FP sends to the GNU Assembler and what that option value actually is. I don't understand how the following are not in contradiction: a) FPC does not specify any particular sub-architecture to the assembler. (me) b) no one seems to know exactly what ARM option FP sends to the GNU Assembler (you) The answer is still FPC passes no ARM sub-architecture option to the assembler. Reading the GNU as manual, the arch parameter value needs to be set to one of several values. It can also specify generic ARM architecture, but that choice in addition to being imprecise, could result in code that either is not optimized for the target ARM processor, or fail to execute as expected. It will at most cause the assembler to reject opcodes for particular ARM sub-architectures that do not exist in the default sub- architecture (which without a doubt is a generic and common ARM variant). Crashes only occur if you tell the assembler to accept e.g. ARMv6 opcodes, and you genere such opcodes, and then you try to run the program on an ARMv4 cpu. I'm not aware of any optimisations that the assembler can perform for different ARM architectures (except for some small THUMB things, but FPC doesn't generate THUMB code). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Porting linux to pascal, would it be, possible ?
Hello Like ti weigh in on this thread in the discussion regarding increasing the GUI-ness of FP. Has anyone looked into writing an Eclipse plug-in for FP (as an was done for Python and Ruby)? Given the huge base of Eclipse users this might be a way to reach the goal with both a better developer tool and plugging into a big audience of potential users. Prince On Sat, Dec 6, 2008 at 10:34 PM, Andrew Haines [EMAIL PROTECTED] wrote: Graeme Geldenhuys wrote: On Fri, Dec 5, 2008 at 5:55 PM, Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote: If you want to do some large work to increase the use of FPC I would recommend creating a Window Manager instead, probably with fpgui. How far did you guys get with the 'fpwm' project? Did it actually run at some point. I see the last code changes was 2 years ago. I just checked out fpwm and updated it and fpgui locally so it can compile. It does almost nothing atm but can reparent and close windows :) not alot. I was thinking I might write a widget for resizing and moving windows. Currently the window title bar is a Label and a Button that has an X for it's text and stdimg.quit as the image. I might work on it some in the coming week if I can find the time. Regards, Andrew ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Porting linux to pascal, would it be, possible ?
On Sun, Dec 7, 2008 at 6:34 AM, Andrew Haines [EMAIL PROTECTED] wrote: I just checked out fpwm and updated it and fpgui locally so it can compile. It does almost nothing atm but can reparent and close windows :) not alot. I was thinking I might write a widget for resizing and moving windows. Currently the window title bar is a Label and a Button that has an X for it's text and stdimg.quit as the image. I might work on it some in the coming week if I can find the time. Umm... I have though of trying my hand at the X11 tutorial on creating a simply window manager, but never got around to it. The last time (years ago) when I tried to compile 'fpwm', I managed to get it to compile, but didn't know how to test/run it. Could you give some hints on the latter, or is there a readme file in the fpwm project that explains this? How do I temporarily test a new window manager? I'm using Ubuntu, and have quite a few window managers available from GDM (sessions menu), but I have no idea how those options got there, or how to add my own. :-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Porting discussion
To increaase compatibility to Linux it would be great if it is possible to create a keyword which it makes possible to include C-headers and then do automatically the binding stuff. That means that fpc woul be able to parse C-code (headers). If that is possible. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Porting discussion
In our previous episode, Rainer Stratmann said: To increaase compatibility to Linux it would be great if it is possible to create a keyword which it makes possible to include C-headers and then do automatically the binding stuff. That means that fpc woul be able to parse C-code (headers). If that is possible. Not, or at least not enough to be robust. A lot of C headers is based on (macro,define) substitution, IOW it needs context of use to obtain the full meaning. This is also why the header conversion tool only works to a certain degree. If headers are reasonably clean it can work ok. If you have hundreds of macros and special constructs it needs manual work. (for which I can't imagine a solution, even in theory). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Support for ARM Architecture
Jonas Maebe wrote: ... the assembler can perform for different ARM architectures (except for some small THUMB things, but FPC doesn't generate THUMB code). I'd wondered about THUMB support. That means no STM-32 processors, as THUMB code is all they execute. Bummer, as they are nice and extremely cheap. Jeff. -- I haven't smoked for 2 years, 3 months and 3 weeks, saving $3,800.16 and not smoking 25,334.45 cigarettes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fstat usage
Francisco Reyes writes:
Trying the fstat function and don't seem to be getting the right values for
ctime, mtime and atime.
-- filedate.pp
uses BaseUnix,DateUtils,SysUtils;
var
info : stat ;
begin
if fpstat ('myfile.txt' , info) 0 then
begin
writeln ('Fstat failed . Errno : ' , fpgeterrno) ;
halt ( 1 ) ;
end ;
writeln ;
writeln ('atime : ' , DateTimeToStr(info.st_atime ));
writeln ('mtime : ' , DateTimeToStr(info.st_mtime ));
writeln ('ctime : ' , DateTimeToStr(info.st_ctime ));
writeln ('Now STR: ', DateTimeToStr(Now));
writeln ('Mod diff:' , DaySpan(Now,info.st_mtime));
writeln ('mtime raw: ', info.st_mtime );
writeln (' Now raw: ', Now);
end .
touch mfyle.txt
fpc filedate.pp
./filedate.pp
atime : 6-9-88--
mtime : 6-9-88--
ctime : 6-9-88--
Now STR: 5-12-08 22:15:08
Mod diff: 1.22849351907281E+009
mtime raw: 1228533307
Now raw: 3.97879271865278E+004
I was expecting atime, mtime and ctime to be very close to 'Now'.
The file date is December 5, 2008 as shown on the OS
ll myfile.txt
-rw-r--r-- 1 fran users 16 2008-12-05 22:15 myfile.txt
What other function can I use instead of fpstat?
Perhaps a different function in another RTL library?
Need to be able to have the program work on both FreeBSD and Linux.
Any pointers greatly appreciated.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Porting linux to pascal, would it be, possible ?
In our previous episode, Prince Riley said: Like ti weigh in on this thread in the discussion regarding increasing the GUI-ness of FP. Has anyone looked into writing an Eclipse plug-in for FP (as an was done for Python and Ruby)? Afaik there was a more editor like plugin at one time. But at that time designer support only existed for C++ and Java. Haven't heard much since. Given the huge base of Eclipse users this might be a way to reach the goal with both a better developer tool and plugging into a big audience of potential users. Afaik most Eclipse users use Java? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Support for ARM Architecture
Am Montag, den 08.12.2008, 10:27 +0100 schrieb Jonas Maebe: On 08 Dec 2008, at 00:33, Prince Riley wrote: Reading the GNU as manual, the arch parameter value needs to be set to one of several values. It can also specify generic ARM architecture, but that choice in addition to being imprecise, could result in code that either is not optimized for the target ARM processor, or fail to execute as expected. It will at most cause the assembler to reject opcodes for particular ARM sub-architectures that do not exist in the default sub- architecture (which without a doubt is a generic and common ARM variant). Crashes only occur if you tell the assembler to accept e.g. ARMv6 opcodes, and you genere such opcodes, and then you try to run the program on an ARMv4 cpu. I'm not aware of any optimisations that the assembler can perform for different ARM architectures (except for some small THUMB things, but FPC doesn't generate THUMB code). One possible difference coming to my mind (although only a speed issue, not influencing nonetheless working code): There are some ARM7 (and maybe ARM9, not sure) core variants having no hardware multiplication unit. IIRC the M in TDMI stands for hardware multiplier unit. Experiences with gcc showed me that the 32x32=64 mult commands are not used in that case. It would be nice to have the chance of setting some extra command line arguments to the call to the assembler - I think that is what Riley is is asking for. From a quick look over the man pages of as and gcc there seems to be no environment variable or such for switching the assembler output code from the outside. Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Support for ARM Architecture
On 08 Dec 2008, at 18:26, Marc Santhoff wrote: There are some ARM7 (and maybe ARM9, not sure) core variants having no hardware multiplication unit. IIRC the M in TDMI stands for hardware multiplier unit. Experiences with gcc showed me that the 32x32=64 mult commands are not used in that case. That's a compiler and not an assembler decision. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object Pascal operating system
Am Montag, den 08.12.2008, 08:19 +0200 schrieb Crause, Christo (JC): Some proof of the concept: ClassiOS (http://www.petros-project.com/index.php/products/classios.html) was written in Delphi. Thanks for pointing this out, I didn't know that one yet. Not an open source project, but it shows it can be done. Sure it can - but is it worth time? One possibility beeing worth the effort might be some sort of micro OS for use on embedded computers with ARM or AVR cpu. This would require writing a small RTL but the overall work is a lot smaller than writing a full OS. But if one needs a TCP stack or display driver or sth. like that the point has come where linking in foreign code starts and the purity of object pascal is gone. Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fstat usage
On Monday 08 December 2008 10:22:25 Francisco Reyes wrote: Francisco Reyes writes: Trying the fstat function and don't seem to be getting the right values for ctime, mtime and atime. Those values are Unix timestamp values. You need to convert them into TDateTime values. Look for UnixToDateTime and DateTimeToUnix in DateUtils. Best regards, Pete C. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Support for ARM Architecture
Am Montag, den 08.12.2008, 19:22 +0100 schrieb Jonas Maebe: On 08 Dec 2008, at 18:26, Marc Santhoff wrote: There are some ARM7 (and maybe ARM9, not sure) core variants having no hardware multiplication unit. IIRC the M in TDMI stands for hardware multiplier unit. Experiences with gcc showed me that the 32x32=64 mult commands are not used in that case. That's a compiler and not an assembler decision. Yes, you're right, sorry. Code generator issue, that is. Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Support for ARM Architecture
Sorry to everyone for replying so far down the thread to the points mentioned earlier. The FPC ARM support is stated as ' does not specify an ARM architecture' ... fine ..but there is a major issue there that needs clarification and better documentation. Is it really safe to have no way to target the entire compiler (FP code and assemble op codes that are passed thru) output to a specific ARM processor? Since the back end GNU as supports several variants of ARM, why is FP limited to an unspecified ARM processor? If FP compiler is outputting ARM assembler code for the entire program, and the assembler ignores invalid ARM opcodes, without specifying what ARM sub-architecture (ARM7, ARM5, ARM9), then what defines which ARM op codes are 'invalid' ? I realize that at the time someone may have thought it really didn't made any difference, but as was mentioned in this post, several ARM processors do not have multipliers. So what happens when one writes a FP function that multiplies two numbers? How does the complier choose to output ARM ADD opcodes instead of MULTIPLY opcodes? Does the FP compiler just use ADD opcodes all the time? What I keep asking here and not getting a precise answer about is what specific ARM opcodes does the FP support What is its default ARM architecture is the opcode spec based on? To be clear ARM5 and ARM7 aren't variants, they are RISC family processors to be sure, but they are 'different.' Perhaps the person who coded that support into FP can write back and say which ARM op codes look-up table it uses generating the FP compiled code. Is it ARM7? Is it ARM9?, Is it ARM4/5? Thanks Prince On Mon, Dec 8, 2008 at 12:27 PM, Marc Santhoff [EMAIL PROTECTED]wrote: Am Montag, den 08.12.2008, 19:22 +0100 schrieb Jonas Maebe: On 08 Dec 2008, at 18:26, Marc Santhoff wrote: There are some ARM7 (and maybe ARM9, not sure) core variants having no hardware multiplication unit. IIRC the M in TDMI stands for hardware multiplier unit. Experiences with gcc showed me that the 32x32=64 mult commands are not used in that case. That's a compiler and not an assembler decision. Yes, you're right, sorry. Code generator issue, that is. Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Support for ARM Architecture
On 08 Dec 2008, at 20:43, Prince Riley wrote: What I keep asking here and not getting a precise answer about is what specific ARM opcodes does the FP support What is its default ARM architecture is the opcode spec based on? The problem was that you never asked for which ARM architecture FPC generates assembler code, but only which ARM sub-architecture parameter FPC passes to the GNU assembler. Those are two completely separate questions (and unrelated in this case). By default, FPC generates ARMv4 architecture code. You can also ask for ARMv5 and ARMv6 code (using the -Cp command line option, see ppcrossarm -i for the possible options). In practice, the only difference at this time is that the prefetch() statement is not translated into assembler code unless you target ARMv6 (because earlier ARM cpus do not have a prefect assembler instruction). To be clear ARM5 and ARM7 aren't variants, they are RISC family processors to be sure, but they are 'different.' They are variants of the same processor family (just like the i386 and the Core2Duo are variants of the same processor family). The fact that they are variants does not mean that they support exactly the same instruction set. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Support for ARM Architecture
Am Montag, den 08.12.2008, 13:43 -0600 schrieb Prince Riley: Perhaps the person who coded that support into FP can write back and say which ARM op codes look-up table it uses generating the FP compiled code. Is it ARM7? Is it ARM9?, Is it ARM4/5? As already mentioned by Jonas: it is the Achitecture v4. Look there for reference: http://www.arm.com/products/CPUs/architecture.html Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Support for ARM Architecture
Sorry, I think you are mistaken.. I did ask which ARM Architecture and if you follow the thread back you'll see I even gave examples of what the assembler options were for ARM Here is the text of that post === Thanks for that reply ... and yes I meant IA32 A few additional points if I may .. When you say the FP supports the ARM architecture my specific question is how does FP 'inform' *the GNU assembler back end of which ARM architecture is intended ..*. The following is just a snippet from the GNU Assembler manual showing the ARM processor option codes ... -mcpu=processor[+extension...] This option speci es the target processor. The assembler will issue an error message if an attempt is made to assemble an instruction which will not execute on the target processor. The following processor names are recognized: arm1, arm2, arm250, arm3, arm6, arm60, arm600, arm610, arm620, arm7, arm7m, arm7d, arm7dm, arm7di, arm7dmi, arm70, arm700, arm700i, arm710, arm710t, arm720, arm720t, arm740t, arm710c, arm7100, arm7500, arm7500fe, arm7t, arm7tdmi, arm8, arm810, strongarm, strongarm1, strongarm110, strongarm1100, strongarm1110, arm9, arm920, arm920t, arm922t, arm940t, arm9tdmi, arm9e, arm946e-r0, arm946e, arm966e-r0, arm966e, arm10t, arm10e, arm1020, arm1020t, arm1020e, ep9312 (ARM920 with Cirrus Maverick coprocessor), i80200 (Intel XScale processor) iwmmxt (Intel(r) XScale processor with Wireless MMX(tm) technology coprocessor) and xscale. The special name all may be used to allow the assembler to accept instructions valid for any ARM processor. In addition to the basic instruction set, the assembler can be told to accept various extension mnemonics that extend the processor using the co-processor instruction space. For example, -mcpu=arm920+maverick is equivalent to specifying -mcpu=ep9312. The following extensions are currently supported: +maverick +iwmmxt and +xscale. *I need to be clear on how FP specifies one of these option and how the 'assemble' directive within the FP syntax is implemented to use ARM register and assembler sematics/syntax which the GNU Assembler assumes will be set by the language 'front end'* == if you look at this list you'll see that ARM3,6, and 7 are among the options. So back then, as I have up to now, I asked which assembler code option ( meaning -- which ARM architecture --) did FP support. On Mon, Dec 8, 2008 at 2:17 PM, Jonas Maebe [EMAIL PROTECTED]wrote: On 08 Dec 2008, at 20:43, Prince Riley wrote: What I keep asking here and not getting a precise answer about is what specific ARM opcodes does the FP support What is its default ARM architecture is the opcode spec based on? The problem was that you never asked for which ARM architecture FPC generates assembler code, but only which ARM sub-architecture parameter FPC passes to the GNU assembler. Those are two completely separate questions (and unrelated in this case). By default, FPC generates ARMv4 architecture code. You can also ask for ARMv5 and ARMv6 code (using the -Cp command line option, see ppcrossarm -i for the possible options). In practice, the only difference at this time is that the prefetch() statement is not translated into assembler code unless you target ARMv6 (because earlier ARM cpus do not have a prefect assembler instruction). To be clear ARM5 and ARM7 aren't variants, they are RISC family processors to be sure, but they are 'different.' They are variants of the same processor family (just like the i386 and the Core2Duo are variants of the same processor family). The fact that they are variants does not mean that they support exactly the same instruction set. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] setting output dir inside fpc's package tree
Hi, I' trying again, apparently I wasn't able to make my problem clear. I want to write a Makefile.fpc for fpcmake that does the same thing as any other package inside the $fpc/packages/extra directory tree. How can I force the output directory of .ppu files to the correct place (being ./units/$cputarget-$ostarget/ if I understand correctly)? I do not see statements enforcing this behaviour in the other Makefile.fpc's I took as example. TIA, Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Support for ARM Architecture
Marc, Just wanted to say thank you for that info.. much obliged. Prince On Mon, Dec 8, 2008 at 2:14 PM, Marc Santhoff [EMAIL PROTECTED]wrote: Am Montag, den 08.12.2008, 13:43 -0600 schrieb Prince Riley: Perhaps the person who coded that support into FP can write back and say which ARM op codes look-up table it uses generating the FP compiled code. Is it ARM7? Is it ARM9?, Is it ARM4/5? As already mentioned by Jonas: it is the Achitecture v4. Look there for reference: http://www.arm.com/products/CPUs/architecture.html Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Support for ARM Architecture
On 08 Dec 2008, at 22:00, Prince Riley wrote: Sorry, I think you are mistaken.. I did ask which ARM Architecture and if you follow the thread back you'll see I even gave examples of what the assembler options were for ARM Here is the text of that post I did not understand your questions that way === Thanks for that reply ... and yes I meant IA32 A few additional points if I may .. When you say the FP supports the ARM architecture my specific question is how does FP 'inform' *the GNU assembler back end of which ARM architecture is intended ..*. Answer: it does not inform the GNU assembler back end of which ARM architecture is intended. The code generator is not the GNU assembler backend. [snip GNU as command line options to select ARM variants] *I need to be clear on how FP specifies one of these option Answer: it does not specify any of those options. and how the 'assemble' directive within the FP syntax is implemented to use ARM register and assembler sematics/syntax which the GNU Assembler assumes will be set by the language 'front end'* Answer: the frontend (the compiler) does not set any architecture option for the GNU assembler. == if you look at this list you'll see that ARM3,6, and 7 are among the options. Yes, but that's not the point. I think the confusion stems from your usage of (GNU) assembler, by which you meant code generator. The code generator is not part of the (GNU) assembler, but part of the compiler. The assemble part of the compiler only consists of either calling an external assembler (such as the GNU assembler) or using the internal assembler (e.g., for IA32 and x86_64) to convert the code generated by the code generator into object code. Code selection happens before that phase. The way it basically works is scanner - parser - code generator - assembler - linker. The scanner converts the source code into tokens, the parser converts those tokens into a parse tree, the code generator converts the parse tree into assembler code, the assembler converts the assembler code into object code, and the linker links together all object code (and libraries) into a program or library. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] setting output dir inside fpc's package tree
On 08 Dec 2008, at 21:58, Marc Santhoff wrote: I' trying again, apparently I wasn't able to make my problem clear. I want to write a Makefile.fpc for fpcmake that does the same thing as any other package inside the $fpc/packages/extra directory tree. How can I force the output directory of .ppu files to the correct place (being ./units/$cputarget-$ostarget/ if I understand correctly)? I do not see statements enforcing this behaviour in the other Makefile.fpc's I took as example. As far as I can tell it's simply the default behaviour of the Makefiles generated by fpcmake: FULL_TARGET=$(CPU_TARGET)-$(OS_TARGET) ... ifneq ($(findstring $(OS_SOURCE),$(LIMIT83fs)),) TARGETSUFFIX=$(OS_TARGET) SOURCESUFFIX=$(OS_SOURCE) else TARGETSUFFIX=$(FULL_TARGET) SOURCESUFFIX=$(FULL_SOURCE) endif ... ifndef COMPILER_UNITTARGETDIR ifdef PACKAGEDIR_MAIN COMPILER_UNITTARGETDIR=$(PACKAGEDIR_MAIN)/units/$(TARGETSUFFIX) else COMPILER_UNITTARGETDIR=units/$(TARGETSUFFIX) endif endif ... ifdef COMPILER_UNITTARGETDIR override FPCOPT+=-FU$(COMPILER_UNITTARGETDIR) ... Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] setting output dir inside fpc's package tree
Am Montag, den 08.12.2008, 22:24 +0100 schrieb Jonas Maebe: As far as I can tell it's simply the default behaviour of the Makefiles generated by fpcmake: LOL, so that's the reason why I cannot find it. Many thanks, Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Support for ARM Architecture
Am Montag, den 08.12.2008, 15:04 -0600 schrieb Prince Riley: Marc, Just wanted to say thank you for that info.. much obliged. If you want to know more about what code the compiler produces there are two more opportunities: First you can tell the compiler to not delete the intermediate assembler files and look inside how statements are translated (e.g. for integer multiplication) by using fpc -a ... Call fpc without arguments for more info. Secondly you can look inside the sources of the compilers code generator itself (no, dunno which file). HTH, Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Free Pascal Support for ARM Architecture
So, the situation is like this: 1) Target ARM architecture needs to be told to FPC since FPC needs this information to do correct code generation. 2) FPC does not inform GNU assembler of intended ARM architecture for which assembler code is generated for, which doesn't prevent GNU as from generating correct binary. 3) GNU as doesn't check if FPC-generated instructions are valid, because it does not know target architecture for which it is assembling. But (as stated in previous point), GNU as is still able to generate correct binary. Correct? Greets, Aleksa On Mon, Dec 8, 2008 at 22:18, Jonas Maebe [EMAIL PROTECTED] wrote: On 08 Dec 2008, at 22:00, Prince Riley wrote: Answer: it does not inform the GNU assembler back end of which ARM architecture is intended. The code generator is not the GNU assembler backend. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Cannot find GTK
Hello: I was trying with some examples about using the GTK library in the FreePascal IDE (the blue screen) and it says that this unit is missing. Despite that, I could compile them all using fpc from the command interpreter. What is happenning? Is there any setting I must change in FP? Thanks a lot Andres. _ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cannot find GTK
Options-Directories-Unit. AFAIK the IDE doesn't read fpc.cfg but it reads its own named fp.cfg. -- View this message in context: http://www.nabble.com/Cannot-find-GTK-tp20905508p20907673.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Embarcadero/CodeGear officialy interested in Firebird and on native versions of Delphi for other operating systems ...
something i just read at http://www.firebirdnews.org and in Marco Cantu's blog ( http://blog.marcocantu.com/blog/coderage_2008_closing .html) Sometimes I just understand those guys. Delphi (as language) by support of FreePascal and Lazarus had been already on Mac and Linux since years! Especially since Lazarus supported GTK2 on Linux and Carbon on Mac. Why are they still busy with other alternatives (Mono/.Net, Java, RealBasic, Ruby, XCode, etc) while what they had been dreaming about is right before their eyes. Yes, FPC and Lazarus is not perfect, but what is?! FPC's FCL and Lazarus' LCL is very much similar and compatible with Delphi's (as product) VCL. Having single codebase for different platforms and OSes is not that hard, though in some special cases it can't be 100% single codebase but it can be solved easily using IFDEFs. Some people (mostly people in this list) have been using Delphi (as language) on more than 16 platforms (including mobile devices), yet they are (Codegear/Embarcadero fan boys) still dreaming about it. My very deep condolence goes to them. :) -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Embarcadero/CodeGear officialy interested in Firebird and on native versions of Delphi for other operating systems ...
Bee -- You make a very excellent point in your post and one that I think doesn't get repeated loudly enough into the ears of the Embarcadero folks. Maybe its time for an open letter posted to these kinds of lists and sending their president a e-mail with the link to read the comments for himself. Market presence, that elusive and ill-defined Holy Grail that Borland chased, is now luring these folks into trying to be too many things to too many people. But what we as developers with the FPC and Lazarus must do more of and be keen about is promoting the benefits you describe and coding projects that will make the case less a matter of loyalty and more a matter of results. The mobile/embedded market is the place every software tool company wants to be right now. It's very difficult to get Embaradero to take their eyes off the .NET market since they have decided to sell $900 development tool sets. We have to be smarter than they are and keep pushing the language toward these new applications. Prince On Mon, Dec 8, 2008 at 9:33 PM, [EMAIL PROTECTED] wrote: something i just read at http://www.firebirdnews.org and in Marco Cantu's blog ( http://blog.marcocantu.com/blog/coderage_2008_closing .html) Sometimes I just understand those guys. Delphi (as language) by support of FreePascal and Lazarus had been already on Mac and Linux since years! Especially since Lazarus supported GTK2 on Linux and Carbon on Mac. Why are they still busy with other alternatives (Mono/.Net, Java, RealBasic, Ruby, XCode, etc) while what they had been dreaming about is right before their eyes. Yes, FPC and Lazarus is not perfect, but what is?! FPC's FCL and Lazarus' LCL is very much similar and compatible with Delphi's (as product) VCL. Having single codebase for different platforms and OSes is not that hard, though in some special cases it can't be 100% single codebase but it can be solved easily using IFDEFs. Some people (mostly people in this list) have been using Delphi (as language) on more than 16 platforms (including mobile devices), yet they are (Codegear/Embarcadero fan boys) still dreaming about it. My very deep condolence goes to them. :) -Bee- has Bee.ography at: http://beeography.wordpress.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fstat usage
Pete Cervasio writes: TDateTime values. Look for UnixToDateTime and DateTimeToUnix in DateUtils. The documentation I have must be old (even though I got it a few days ago from the website). It says those functions are not implemented, yet I was able to use it. Is the time displayed in UTC? Seems to be. Any way to make the time displayed be my timezone? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fstat usage
Francisco Reyes writes: Is the time displayed in UTC? Seems to be. Any way to make the time displayed be my timezone? Nevermind that... Was confused because the date was in a different format.. You pointed me in the right direction and finished the program. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
