Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
Hans-Peter Diettrich wrote: IMO CodeGear stumbled with Delphi.NET over the same stone as with Kylix: the Win32 centric VCL :-( I don't think that the VCL was the issue with Kylix. The issues were (a) uncertainty over the Linux community's acceptance of a non-free development environment and (b) the difficulty of having a binary release which was guaranteed to install on any distro or version. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 8 Aug 2011, at 21:13, Florian Klämpfl wrote: Am 08.08.2011 12:49, schrieb John Clymer: Kicking it around in the back of my head at work today... I tried doing a compile to assembly language for the stellaris - and it choked giving the error from t_embed.pas. The error comes from the portion of the program trying to generate a linker script. Looking at t_embed.pas, it looks like every single flavor of ARM controller will require it's own subsection of the case() statement. This can easily get long and ugly. As the only thing that changes between most of the arm variants is the memory layout - why not provide a generic stellaris switch - with reads in a text file containing the memory map and stack top (the rest of the link file remains the same for all variants of ARM) ? This way - switching to a new variant of stellaris only requires tweaking a memory map file - rather than a re-build and patch of t_embed.pas ? For that matter - entirely foreign Cortex M3 parts could be easily supported without requiring changes to the compiler. Just pondering how to make it easier and more flexible ... Yes, this can be done. However, somebody who knows enough about a certain controller family must do this. What in your view is the best way to separate link options such as these variations in memory maps between devices? I often have several projects at once and they can be using different parts within the same family; having to re-compile the compiler when switching between projects is not ideal. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Arm Thumb2 - Stellaris status
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Geoffrey Barton Envoyé : mardi 9 août 2011 10:20 À : FPC developers' list Objet : Re: [fpc-devel] Arm Thumb2 - Stellaris status On 8 Aug 2011, at 21:13, Florian Klämpfl wrote: Am 08.08.2011 12:49, schrieb John Clymer: Kicking it around in the back of my head at work today... I tried doing a compile to assembly language for the stellaris - and it choked giving the error from t_embed.pas. The error comes from the portion of the program trying to generate a linker script. Looking at t_embed.pas, it looks like every single flavor of ARM controller will require it's own subsection of the case() statement. This can easily get long and ugly. As the only thing that changes between most of the arm variants is the memory layout - why not provide a generic stellaris switch - with reads in a text file containing the memory map and stack top (the rest of the link file remains the same for all variants of ARM) ? This way - switching to a new variant of stellaris only requires tweaking a memory map file - rather than a re-build and patch of t_embed.pas ? For that matter - entirely foreign Cortex M3 parts could be easily supported without requiring changes to the compiler. Just pondering how to make it easier and more flexible ... Yes, this can be done. However, somebody who knows enough about a certain controller family must do this. What in your view is the best way to separate link options such as these variations in memory maps between devices? I often have several projects at once and they can be using different parts within the same family; having to re-compile the compiler when switching between projects is not ideal. What about adding some command line options similar to -WB: -WB4 sets the default load address of Windows PE executables to 0x4. Its value is stored in global variable ImageBase. If only four or five values need to be set, we could just implement option -WE option: E for embedded, with -WEFlashOriginHexDecimalValue -WEFlashLengthHexDecimalValue -WERamOriginHexDecimalValue -WERamLengthHexDecimalValue -WEStackTopHexDecimalValue Of course, this depends if the list of required values is limited or not. Another problem is if the script should include or not those lines. But here also, we could create a list of args, some would be tagged as having a default value, which would be used if no command line option is given, while other args would have no default, meaning that the linker line would only be inserted if the corresponding value are set at command line. If that case, it might be better to combine Origin and Length into a unique argument -WEFlashHexValueOfOrigin-HexValueOfLength where HexValueOfOrigin and HexValueOfLength would both bereplaced by the valid values in order to avoid having only Origin and no Length for Flash (or Ram, or anything else that would be needed). Maybe a special 'custom' controller type would be handy for this... Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
In our previous episode, Mark Morgan Lloyd said: [ Charset windows-1252 unsupported, converting... ] Hans-Peter Diettrich wrote: IMO CodeGear stumbled with Delphi.NET over the same stone as with Kylix: the Win32 centric VCL :-( I don't think that the VCL was the issue with Kylix. The issues were (a) uncertainty over the Linux community's acceptance of a non-free development environment and (b) the difficulty of having a binary release which was guaranteed to install on any distro or version. c) betting on a desktop Linux revolution that never really came. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 9 August 2011 09:49, Mark Morgan Lloyd wrote: I don't think that the VCL was the issue with Kylix. The issues were (a) uncertainty over the Linux community's acceptance of a non-free development Add to that list: - CLX was buggy as hell because they didn't even write the Kylix IDE using CLX. - Developers kept comparing VCL to CLX because Borland marketed it like that. They should have done what EMB is doing with FireMonkey. Clearly state it is a different framework that will have the RTL and other non-gui code in common. - They priced Kylix way to high in the beginning. - CLX was never updated to Qt 3 when it came out. CLX was based on Qt 2.2 or something like that. I'm pretty sure Kylix and CLX would have worked if Borland just paid a bit more attention to quality and better marketing. Oh well, that's all done and dusted. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 08/08/2011 10:00 PM, Sven Barth wrote: It will be interesting to see whether they want to license Cooper, RemObject's upcoming Pascal compiler for Java, as well; their plans to support Android as well in the future could mean this. Of course Cooper would be a way to support Android for framework based apps. Additionally, KSD (the name of FireMonkey before Embarcadero bought it) supports ARM Linux and it should be possible to make it run as a native application on an ARM based Android (same for x86 based Androids). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On 08/09/2011 11:28 AM, Graeme Geldenhuys wrote: I'm pretty sure Kylix and CLX would have worked if Borland just paid a bit more attention to quality and better marketing. +1 -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
I was thinking more of a generic controller class, including a memory.def (or
whatever one wants to name it) file. That would be easiest as it would only
effect the t_embed.pas file (and cpuinfo.pas file to add the generic type.)
Haven't looked into possibly a compiler option (and may easily be more trouble
than a command line option):
{$ARM_FLASH_START }
{$ARM_FLASH_LENGTH }
{$ARM_SRAM_START }
{$ARM_SRAM_LENGTH }
But, I still think a static memory definition file would require the least
amount of code changes. And would only effect only the ARM related files.
John
From: Pierre Free Pascal pie...@freepascal.org
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, August 9, 2011 1:00:53 PM
Subject: RE: [fpc-devel] Arm Thumb2 - Stellaris status
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Geoffrey Barton
Envoyé : mardi 9 août 2011 10:20
À : FPC developers' list
Objet : Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 8 Aug 2011, at 21:13, Florian Klämpfl wrote:
Am 08.08.2011 12:49, schrieb John Clymer:
Kicking it around in the back of my head at work today...
I tried doing a compile to assembly language for the stellaris - and it
choked giving the error from t_embed.pas. The error comes from the
portion of the program trying to generate a linker script.
Looking at t_embed.pas, it looks like every single flavor of ARM
controller will require it's own subsection of the case() statement.
This can easily get long and ugly. As the only thing that changes
between most of the arm variants is the memory layout - why not provide
a generic stellaris switch - with reads in a text file containing the
memory map and stack top (the rest of the link file remains the same
for
all variants of ARM) ?
This way - switching to a new variant of stellaris only requires
tweaking a memory map file - rather than a re-build and patch of
t_embed.pas ? For that matter - entirely foreign Cortex M3 parts could
be easily supported without requiring changes to the compiler.
Just pondering how to make it easier and more flexible ...
Yes, this can be done. However, somebody who knows enough about a
certain controller family must do this.
What in your view is the best way to separate link options such as these
variations in memory maps between devices? I often have several projects
at
once and they can be using different parts within the same family; having
to
re-compile the compiler when switching between projects is not ideal.
What about adding some command line options
similar to -WB:
-WB4
sets the default load address of Windows PE executables
to 0x4. Its value is stored in global variable ImageBase.
If only four or five values need to be set, we could just
implement option -WE option:
E for embedded,
with
-WEFlashOriginHexDecimalValue
-WEFlashLengthHexDecimalValue
-WERamOriginHexDecimalValue
-WERamLengthHexDecimalValue
-WEStackTopHexDecimalValue
Of course, this depends if the list of required values is limited or not.
Another problem is if the script should include or not those
lines.
But here also, we could create a list of args,
some would be tagged as having a default value, which would be used
if no command line option is given, while other args would
have no default, meaning that the linker line would only be inserted
if the corresponding value are set at command line.
If that case, it might be better to combine Origin and Length into a
unique
argument
-WEFlashHexValueOfOrigin-HexValueOfLength
where HexValueOfOrigin and HexValueOfLength would both bereplaced by
the valid values in order to avoid having only Origin and no Length for
Flash (or Ram, or anything else that would be needed).
Maybe a special 'custom' controller type would be handy for this...
Pierre Muller
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 9 Aug 2011, at 14:14, John Clymer wrote:
I was thinking more of a generic controller class, including a memory.def (or
whatever one wants to name it) file. That would be easiest as it would only
effect the t_embed.pas file (and cpuinfo.pas file to add the generic type.)
Haven't looked into possibly a compiler option (and may easily be more
trouble than a command line option):
{$ARM_FLASH_START }
{$ARM_FLASH_LENGTH }
{$ARM_SRAM_START }
{$ARM_SRAM_LENGTH }
But, I still think a static memory definition file would require the least
amount of code changes. And would only effect only the ARM related files.
The compiler option works well when you have conditional options for different
target builds using ifdefs, which I do I lot. It makes it very easy to see if
it is in the source file as it can be locked to other options and you only need
to select it in one place.
A separate linker file starts to make FPC handle like any other compiler :(
instead of the joy to use it is :)
Geoffrey
John
From: Pierre Free Pascal pie...@freepascal.org
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, August 9, 2011 1:00:53 PM
Subject: RE: [fpc-devel] Arm Thumb2 - Stellaris status
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Geoffrey Barton
Envoyé : mardi 9 août 2011 10:20
À : FPC developers' list
Objet : Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 8 Aug 2011, at 21:13, Florian Klämpfl wrote:
Am 08.08.2011 12:49, schrieb John Clymer:
Kicking it around in the back of my head at work today...
I tried doing a compile to assembly language for the stellaris - and it
choked giving the error from t_embed.pas. The error comes from the
portion of the program trying to generate a linker script.
Looking at t_embed.pas, it looks like every single flavor of ARM
controller will require it's own subsection of the case() statement.
This can easily get long and ugly. As the only thing that changes
between most of the arm variants is the memory layout - why not provide
a generic stellaris switch - with reads in a text file containing the
memory map and stack top (the rest of the link file remains the same
for
all variants of ARM) ?
This way - switching to a new variant of stellaris only requires
tweaking a memory map file - rather than a re-build and patch of
t_embed.pas ? For that matter - entirely foreign Cortex M3 parts could
be easily supported without requiring changes to the compiler.
Just pondering how to make it easier and more flexible ...
Yes, this can be done. However, somebody who knows enough about a
certain controller family must do this.
What in your view is the best way to separate link options such as these
variations in memory maps between devices? I often have several projects
at
once and they can be using different parts within the same family; having
to
re-compile the compiler when switching between projects is not ideal.
What about adding some command line options
similar to -WB:
-WB4
sets the default load address of Windows PE executables
to 0x4. Its value is stored in global variable ImageBase.
If only four or five values need to be set, we could just
implement option -WE option:
E for embedded,
with
-WEFlashOriginHexDecimalValue
-WEFlashLengthHexDecimalValue
-WERamOriginHexDecimalValue
-WERamLengthHexDecimalValue
-WEStackTopHexDecimalValue
Of course, this depends if the list of required values is limited or not.
Another problem is if the script should include or not those
lines.
But here also, we could create a list of args,
some would be tagged as having a default value, which would be used
if no command line option is given, while other args would
have no default, meaning that the linker line would only be inserted
if the corresponding value are set at command line.
If that case, it might be better to combine Origin and Length into a
unique
argument
-WEFlashHexValueOfOrigin-HexValueOfLength
where HexValueOfOrigin and HexValueOfLength would both bereplaced by
the valid values in order to avoid having only Origin and no Length for
Flash (or Ram, or anything else that would be needed).
Maybe a special 'custom' controller type would be handy for this...
Pierre Muller
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
For what it's worth, IAR's C compiler for Cortex-M3 uses an ICF file
to hold that information, so there is precedent for doing it that way.
It holds the following (edited slightly to remove fluff):
define symbol __ICFEDIT_intvec_start__ = 0x0800;
define symbol __ICFEDIT_region_ROM_start__ = 0x08EC;
define symbol __ICFEDIT_region_ROM_end__ = 0x0801EFFF;
define symbol __ICFEDIT_region_RAM_start__ = 0x2000;
define symbol __ICFEDIT_region_RAM_end__ = 0x20004FFF;
define symbol __ICFEDIT_size_cstack__ = 0x400;
define symbol __ICFEDIT_size_heap__ = 0x4;
define memory mem with size = 4G;
define region ROM_region = mem:[from __ICFEDIT_region_ROM_start__
to __ICFEDIT_region_ROM_end__];
define region RAM_region = mem:[from __ICFEDIT_region_RAM_start__
to __ICFEDIT_region_RAM_end__];
define block CSTACKwith alignment = 8, size = __ICFEDIT_size_cstack__ { };
define block HEAP with alignment = 8, size = __ICFEDIT_size_heap__ { };
initialize by copy { readwrite };
do not initialize { section .noinit };
place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };
place in ROM_region { readonly };
place in RAM_region { readwrite,
block CSTACK, block HEAP };
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
On 09-08-2011 15:53, Geoffrey Barton wrote:
On 9 Aug 2011, at 14:14, John Clymer wrote:
I was thinking more of a generic controller class, including a
memory.def (or whatever one wants to name it) file. That would be
easiest as it would only effect the t_embed.pas file (and cpuinfo.pas
file to add the generic type.)
Haven't looked into possibly a compiler option (and may easily be
more trouble than a command line option):
{$ARM_FLASH_START }
{$ARM_FLASH_LENGTH }
{$ARM_SRAM_START }
{$ARM_SRAM_LENGTH }
But, I still think a static memory definition file would require the
least amount of code changes. And would only effect only the ARM
related files.
The compiler option works well when you have conditional options for
different target builds using ifdefs, which I do I lot. It makes it
very easy to see if it is in the source file as it can be locked to
other options and you only need to select it in one place.
A separate linker file starts to make FPC handle like any other
compiler :( instead of the joy to use it is :)
I agree. Keeping the configurations in code is easier to manage,
compared to the spiderweb of magically named files of other embedded
compilers
I think that maybe creating an abstract class hierachy of chip families,
instead of the current solution of a single large case statement, would
be a better solution in the long run
Geoffrey
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
DaWorm schrieb: For what it's worth, IAR's C compiler for Cortex-M3 uses an ICF file to hold that information, so there is precedent for doing it that way. It holds the following (edited slightly to remove fluff): [...] IMO these are all values required by the linker, not by the compiler itself. Both an internal or external linker should read these definitions from an ICF (or similar) file. The name of that file, or of the concrete device, can be passed to the linker as a commandline argument. Some tables (devices) can be added to the linker code, of course, in detail when the devices also require specific linker code (in subclasses). [dunno about concrete requirements] DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Am 09.08.2011 17:04, schrieb Jeppe Græsdal Johansen:
On 09-08-2011 15:53, Geoffrey Barton wrote:
On 9 Aug 2011, at 14:14, John Clymer wrote:
I was thinking more of a generic controller class, including a
memory.def (or whatever one wants to name it) file. That would be
easiest as it would only effect the t_embed.pas file (and cpuinfo.pas
file to add the generic type.)
Haven't looked into possibly a compiler option (and may easily be
more trouble than a command line option):
{$ARM_FLASH_START }
{$ARM_FLASH_LENGTH }
{$ARM_SRAM_START }
{$ARM_SRAM_LENGTH }
But, I still think a static memory definition file would require the
least amount of code changes. And would only effect only the ARM
related files.
The compiler option works well when you have conditional options for
different target builds using ifdefs, which I do I lot. It makes it
very easy to see if it is in the source file as it can be locked to
other options and you only need to select it in one place.
A separate linker file starts to make FPC handle like any other
compiler :( instead of the joy to use it is :)
I agree. Keeping the configurations in code is easier to manage,
Yes. I think as well that everything should stick in the compiler. FPC
is open source, so no need for a convolution of compiler support and
external files. Full support of all devices will lead to a huge number
of interwinded include files in the rtl anyways.
compared to the spiderweb of magically named files of other embedded
compilers
I think that maybe creating an abstract class hierachy of chip families,
instead of the current solution of a single large case statement, would
be a better solution in the long run
Well, it can be done also by some sets like
controllers_stellaris128flash64ram. I don't think that a big full
fledged class hierary is needed. Even the case statement might be
sufficient.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] make fcl-base for arm-wince failure in fpc 2.7.1
On Mon, 2011-08-08 at 14:57 +0200, Vincent Snijders wrote: It seems that the conversion of fcl-base to fpmake still has a glitch: Can you test with r18155? Joost. -- My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] make fcl-base for arm-wince failure in fpc 2.7.1
2011/8/9 Joost van der Sluis jo...@cnoc.nl: On Mon, 2011-08-08 at 14:57 +0200, Vincent Snijders wrote: It seems that the conversion of fcl-base to fpmake still has a glitch: Can you test with r18155? It works, thanks, Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
