Re: [fpc-devel] ARM vs Thumb2 - can't have both
Most if not all of my references to thumb meant the original ARMv4T thumb instruction set, definitely not the thumb2 extensions, nor ARMv5 or ARMv6 extensions. If for example you had a thumb backend to fpc, you could easily solve this problem, all of these libraries would run on both platforms, one compiler, one set of libraries, compiled one time. There is no thumb backend at the moment, this is the first problem to that solution. I figure most folks would not want to sink to the lowest common denominator. I would then recommend splitting the arm/arm7/ARMv4 architecture from the cortex-m3/ARMv7m, as implemented now they are two incompatible instruction sets. One instruction set happens to share the name of the company, move beyond that sticking point and create two architectures. The third alternative is do what others do and build two sets of libraries, one for each cpu type if that is the preferred term to distinguish arm and thumb2. Even if they are in the same library file but by name the linker extracts the arm cpu whatsit function from the thumb2 cpu whatsit function it is still two compilations of the whatsit function. You really have to pick one of those solutions, same instruction set or compile the libraries twice either as two arches build one or the other but not both, or two cpus within an arch and both/all cpus for an arch get built when the arch compiler is built. David On 08/22/2011 01:15 AM, John Clymer wrote: Yes, all my references of Thumb meant Thumb2. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM vs Thumb2 - can't have both
On 08/23/2011 08:39 AM, David Welch wrote: I figure most folks would not want to sink to the lowest common denominator. I feel that M3 and friends might be worth investing in thumb support for embedded devices. But I understand that the more relevant targets for ARM-FPC seem to be Smartphones, Tablet PCs, mini-Servers and upcoming high performance cortex A15 Servers. Her I feel that thumb does not make much sense, while most legacy ARM hardware does not _need_ thumb based software, even it would be able to run it. Just my version of the rule of thumb. :) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] strcopy, strlcopy for PWideChar
Florian Klämpfl wrote / napísal(a): Am 16.08.2011 07:06, schrieb LacaK: Hans-Peter Diettrich wrote / napísal(a): LacaK schrieb: Or do you not like these wide versions at all ? It's not a matter of liking, I'm afraid. If Delphi has them, we'll have to add them too :-) Can you please add an entry in the bug tracker, so we don't forget ? http://bugs.freepascal.org/view.php?id=19989 Do you think, that it is realistic expect them in 1-2 months ? Supply an patch, to speed up the implementation. Ok, I can try prepare patch, but only generic i.e. which uses only Pascal. It's the prefered way anyways. First, make a good pascal version, if someone needs it, he can look into creating an assembler one for some cpus. I posted generic pascal versions in bug report http://bugs.freepascal.org/view.php?id=19989#bugnotes Please review (and commit if all ok). Thanks -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ARM vs Thumb2 - can't have both
Digging some more around it today, came up with the following idea... In the rtl/embedded folder - there is the system file for ARM - it is ALL pascal - and compiles to either of Thumb2 or ARMV4 - but not both. In that folder's Makefile.fpc, the units to be built are listed - the could be switched to listing directories to get built. One folder for ARMV4, one for Thumb2. A system file and rtl.cfg file sits in each folder. The system file just bounces back down and includes the current system files from the rtl/embedded folder, but the library gets built in the core specific folder. That's the easy part, the more difficult part will to be to get the compiler to choose the correct system file. That is, the usual ARM folder where the libraries sit would need to have the same 2 seperate subdirectorie, the compiler would have to choose which one based on the core it's currently compiling for. John From: David Welch dwe...@dwelch.com To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Tue, August 23, 2011 10:39:50 AM Subject: Re: [fpc-devel] ARM vs Thumb2 - can't have both Most if not all of my references to thumb meant the original ARMv4T thumb instruction set, definitely not the thumb2 extensions, nor ARMv5 or ARMv6 extensions. If for example you had a thumb backend to fpc, you could easily solve this problem, all of these libraries would run on both platforms, one compiler, one set of libraries, compiled one time. There is no thumb backend at the moment, this is the first problem to that solution. I figure most folks would not want to sink to the lowest common denominator. I would then recommend splitting the arm/arm7/ARMv4 architecture from the cortex-m3/ARMv7m, as implemented now they are two incompatible instruction sets. One instruction set happens to share the name of the company, move beyond that sticking point and create two architectures. The third alternative is do what others do and build two sets of libraries, one for each cpu type if that is the preferred term to distinguish arm and thumb2. Even if they are in the same library file but by name the linker extracts the arm cpu whatsit function from the thumb2 cpu whatsit function it is still two compilations of the whatsit function. You really have to pick one of those solutions, same instruction set or compile the libraries twice either as two arches build one or the other but not both, or two cpus within an arch and both/all cpus for an arch get built when the arch compiler is built. David On 08/22/2011 01:15 AM, John Clymer wrote: Yes, all my references of Thumb meant Thumb2. ___ 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 vs Thumb2 - can't have both
Is it really that big a deal? I think the negatives outweigh the positives in the changes implied here. Say what you want about the priciples about the instruction sets(ARM and Thumb2), but they still share 95% of the backend code. When you're dealing with lowlevel targets like embedded arm you'll still need to know the RTL code pretty well. The build system isn't really very complex either. I personally see no reason to change the way it is Den 23-08-2011 16:01, John Clymer skrev: Digging some more around it today, came up with the following idea... In the rtl/embedded folder - there is the system file for ARM - it is ALL pascal - and compiles to either of Thumb2 or ARMV4 - but not both. In that folder's Makefile.fpc, the units to be built are listed - the could be switched to listing directories to get built. One folder for ARMV4, one for Thumb2. A system file and rtl.cfg file sits in each folder. The system file just bounces back down and includes the current system files from the rtl/embedded folder, but the library gets built in the core specific folder. That's the easy part, the more difficult part will to be to get the compiler to choose the correct system file. That is, the usual ARM folder where the libraries sit would need to have the same 2 seperate subdirectorie, the compiler would have to choose which one based on the core it's currently compiling for. John *From:* David Welch dwe...@dwelch.com *To:* FPC developers' list fpc-devel@lists.freepascal.org *Sent:* Tue, August 23, 2011 10:39:50 AM *Subject:* Re: [fpc-devel] ARM vs Thumb2 - can't have both Most if not all of my references to thumb meant the original ARMv4T thumb instruction set, definitely not the thumb2 extensions, nor ARMv5 or ARMv6 extensions. If for example you had a thumb backend to fpc, you could easily solve this problem, all of these libraries would run on both platforms, one compiler, one set of libraries, compiled one time. There is no thumb backend at the moment, this is the first problem to that solution. I figure most folks would not want to sink to the lowest common denominator. I would then recommend splitting the arm/arm7/ARMv4 architecture from the cortex-m3/ARMv7m, as implemented now they are two incompatible instruction sets. One instruction set happens to share the name of the company, move beyond that sticking point and create two architectures. The third alternative is do what others do and build two sets of libraries, one for each cpu type if that is the preferred term to distinguish arm and thumb2. Even if they are in the same library file but by name the linker extracts the arm cpu whatsit function from the thumb2 cpu whatsit function it is still two compilations of the whatsit function. You really have to pick one of those solutions, same instruction set or compile the libraries twice either as two arches build one or the other but not both, or two cpus within an arch and both/all cpus for an arch get built when the arch compiler is built. David On 08/22/2011 01:15 AM, John Clymer wrote: Yes, all my references of Thumb meant Thumb2. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org mailto: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 vs Thumb2 - can't have both
The only major issue is if you want to build for Thumb2 - you have to manually edit makefiles - because the full ARM cores support and startup files will choke the build process. i.e. Building for Thumb2 with the freshly checked out subversion, when the compiler gets to compiling rtl/embedded/arm/lpc21x4.pp - it will choke because there are non-Thumb2 instructions in the boot code. I just submitted a potential patch to the mailing list to switch the controllers arrays to structures - part of that patch has ifdef's in the controller files lpc21x4's and at91sam7x256's - so that when compiling for Thumb2 - the boot code for those controllers gets bypassed. However, part of the confusion is that if you want Thumb2 RTL's - you have to append an extra option to Make process - otherwise, the RTL will compile - but it will choke on real hardware. There has been discussion on how the RTL should include every register for every machine - to make the user's life easier. Yet - how easy is it to switch from Thumb2 to ARMV4 chips with the current setup ? In order to do that now, you need two different RTL's - via either separate compiles of the compiler - or different CFG files in the project directory (pointing to different system libraries). If we are looking to save the user time by defining every peripheral register - why not save them time by not having to become a compiler expert ? Again, these are my (sometimes random) thoughts on trying to make things easier for the end user. someone that wants to write controller code - not fitz with the compiler. That said, school is starting - and I have a working compiler - so I am just as content to leave the status quo be... John From: Jeppe Græsdal Johansen jjoha...@student.aau.dk To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Tue, August 23, 2011 7:42:51 PM Subject: Re: [fpc-devel] ARM vs Thumb2 - can't have both Is it really that big a deal? I think the negatives outweigh the positives in the changes implied here. Say what you want about the priciples about the instruction sets(ARM and Thumb2), but they still share 95% of the backend code. When you're dealing with lowlevel targets like embedded arm you'll still need to know the RTL code pretty well. The build system isn't really very complex either. I personally see no reason to change the way it is Den 23-08-2011 16:01, John Clymer skrev: Digging some more around it today, came up with the following idea... In the rtl/embedded folder - there is the system file for ARM - it is ALL pascal - and compiles to either of Thumb2 or ARMV4 - but not both. In that folder's Makefile.fpc, the units to be built are listed - the could be switched to listing directories to get built. One folder for ARMV4, one for Thumb2. A system file and rtl.cfg file sits in each folder. The system file just bounces back down and includes the current system files from the rtl/embedded folder, but the library gets built in the core specific folder. That's the easy part, the more difficult part will to be to get the compiler to choose the correct system file. That is, the usual ARM folder where the libraries sit would need to have the same 2 seperate subdirectorie, the compiler would have to choose which one based on the core it's currently compiling for. John From: David Welch dwe...@dwelch.com To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Tue, August 23, 2011 10:39:50 AM Subject: Re: [fpc-devel] ARM vs Thumb2 - can't have both Most if not all of my references to thumb meant the original ARMv4T thumb instruction set, definitely not the thumb2 extensions, nor ARMv5 or ARMv6 extensions. If for example you had a thumb backend to fpc, you could easily solve this problem, all of these libraries would run on both platforms, one compiler, one set of libraries, compiled one time. There is no thumb backend at the moment, this is the first problem to that solution. I figure most folks would not want to sink to the lowest common denominator. I would then recommend splitting the arm/arm7/ARMv4 architecture from the cortex-m3/ARMv7m, as implemented now they are two incompatible instruction sets. One instruction set happens to share the name of the company, move beyond that sticking point and create two architectures. The third alternative is do what others do and build two sets of libraries, one for each cpu type if that is the preferred term to distinguish arm and thumb2. Even if they are in the same library file but by
