* Re: [RFC PATCH 0/9] Thumb-2 ISA kernel port [not found] <20070606172409.6689.26641.stgit@localhost.localdomain> @ 2007-06-06 18:29 ` Sam Ravnborg 2007-06-06 20:47 ` Russell King - ARM Linux ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Sam Ravnborg @ 2007-06-06 18:29 UTC (permalink / raw) To: Catalin Marinas, linux-arch; +Cc: linux-arm-kernel On Wed, Jun 06, 2007 at 06:24:53PM +0100, Catalin Marinas wrote: > The following series of patches add support for compiling the kernel > to the Thumb-2 ISA on an ARMv7 CPU. > > Because of the issues listed below, merging the Thumb-2 support into > the existing arch/arm files would clutter the existing code with > macros like ARM, THUMB or W (for conditional compilation and the wide > instruction format). The IT instruction is also not recognised by > older toolchains and additional (assembler) macros would be needed, > including support for the inline assembly. I therefore decided to > create a separate arch/arm_t2 directory that shares a lot of code with > the existing arch/arm. Hi Catalin. Can you please share with us the strong arguments why another (third) arm architecture are needed? Browsing through your patches there seems to be a common pattern: 1) Adding a bit more info to many assembler function 2) Small modifications to assembler function 3) Almost replaced assembler functions 4) Simpler Kconfig and Makefile 1) Could be solved in trivial ways using a few macros. One example: .type printhex8, %function Add a common macro like this: #define FUNCTION(name) .type name, %function Introducing this simple macro in the generic ARM codebase would bring down the diff significantly 2) For some parts it looked like: "We can do this different so lets do it different" I am rather ARM assembler ignorant so that may not hold true. But if it is true then look into what is really needed to change and if nothing else factor these out in files for the different situations and select the right one in the Makefile. 3) Factor these out in separate files. 4) Short term win. The maintenance will be much simpler avoiding the cleanup. As you are introducing a new architecture I have added linux-arch to list of receivers - maybe someone there has more to say. Sam [Rest of mail kept so linux-arch readers can see it] Pointers to the mails with patches: http://marc.info/?l=linux-arm-kernel&m=118115330624752&w=2 http://marc.info/?l=linux-arm-kernel&m=118115324023036&w=2 http://marc.info/?l=linux-arm-kernel&m=118115281427358&w=2 [PATCH 4/9] was not available at marc.info yet [PATCH 5/9] was not available at marc.info yet http://marc.info/?l=linux-arm-kernel&m=118115384801763&w=2 http://marc.info/?l=linux-arm-kernel&m=118115310810711&w=2 http://marc.info/?l=linux-arm-kernel&m=118115399504496&w=2 http://marc.info/?l=linux-arm-kernel&m=118115421005454&w=2 See full list at: http://marc.info/?l=linux-arm-kernel&r=1&b=200706&w=2 > > I avoided posting the first big patch in the series as it only > contains the code duplicated from arch/arm into arch/arm_t2. Most of > the .h files only contain an #include clause to the corresponding > asm-arm version. Subsequent patches would show the differences with > the original arch/arm code, making the review a lot easier. > > The patches are also available on my GIT tree - > http://www.linux-arm.org/git?p=linux-2.6.git;a=shortlog;h=2.6.21-thumb. > They are currently based on 2.6.21 with some additional patches for > the ARMv7 support (most of them being already merged by Russell in > 2.6.22-rc1). > > Thumb-2 ISA consists of either 16 or 32 bit instructions and are > aligned to a two-byte boundary. ARM defined the unified assembler > language that provides a canonical form for all the ARM and Thumb-2 > instructions. This is currently supported by the CodeSourcery's > toolchains. > > Even with the unified syntax, there are some differences between the > instructions supported in ARM or Thumb modes (though the Thumb-2 code > could be compiled into ARM code but with some performance penalties). > > > Some of the main points regarding the Thumb-2 ISA: > > - conditional execution is achieved using the IT (if-then) instruction > which can specify the execution of up to four subsequent > instructions (when compiling to ARM mode, this instruction is > ignored) > > - post-indexing ldr/str with a register (ldr r0, [r1], r2) is not > supported in Thumb-2 > > - pre-indexing ldr/str with a shifted register only "lsl" is allowed > (ldr r0, [r1, r2, lsl #2]) > > - ldrt/strt do not support post-indexing > > - ldm/stm cannot have "sp" in the register list (the latest ARM ARM > also states that ARM instructions that include "sp" in the list are > deprecated) > > - ldm cannot have both "pc" and "lr" in the list (the latest ARM ARM > also states that these ARM instructions are deprecated) > > - ldm/stm <registers-without-pc>^ are not available (kernel access to > the banked "sp" and "lr" is done by switching to the System mode) > > - ldm <registers-with-pc>^ is not available (return from exception is > done with the "rfe" instruction) > > - ldmda/stmib are not available > > > Some other issues with Thumb-2 or the unified assembler syntax: > > - the condition flags should always be placed at the end of the > instruction, i.e. "ldmiane" rather than "ldmneia". The new form is > not compilable by older assemblers (though the new assembler could > be modified to not warn about the old syntax) > > - because Thumb-2 instructions are 16 bit aligned, instructions > loading data from the literal pool may trigger an alignment > fault. The assembler doesn't automatically align ".word" or ".long" > declarations to 32 bit. This has to be explicitly set via ".align" > > - Thumb-2 32 bit instructions can be generated by appending ".w" to > the instruction, i.e. "mov.w pc, lr" > > > Comments and suggestions are welcomed. > > Regards. > > -- > Catalin > > ------------------------------------------------------------------- > List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel > FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php > Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 0/9] Thumb-2 ISA kernel port 2007-06-06 18:29 ` [RFC PATCH 0/9] Thumb-2 ISA kernel port Sam Ravnborg @ 2007-06-06 20:47 ` Russell King - ARM Linux 2007-06-06 21:10 ` Sam Ravnborg 2007-06-06 22:02 ` Catalin Marinas 2007-06-07 21:05 ` Ralf Baechle 2 siblings, 1 reply; 8+ messages in thread From: Russell King - ARM Linux @ 2007-06-06 20:47 UTC (permalink / raw) To: Sam Ravnborg; +Cc: Catalin Marinas, linux-arch, linux-arm-kernel On Wed, Jun 06, 2007 at 08:29:14PM +0200, Sam Ravnborg wrote: > #define FUNCTION(name) .type name, %function > Introducing this simple macro in the generic ARM codebase would > bring down the diff significantly We have such a macro already - ENDPROC(). Recently introduced, we should probably make more use of it. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 0/9] Thumb-2 ISA kernel port 2007-06-06 20:47 ` Russell King - ARM Linux @ 2007-06-06 21:10 ` Sam Ravnborg 2007-06-06 21:19 ` Catalin Marinas 2007-06-06 22:01 ` Russell King - ARM Linux 0 siblings, 2 replies; 8+ messages in thread From: Sam Ravnborg @ 2007-06-06 21:10 UTC (permalink / raw) To: Russell King - ARM Linux; +Cc: Catalin Marinas, linux-arch, linux-arm-kernel On Wed, Jun 06, 2007 at 09:47:49PM +0100, Russell King - ARM Linux wrote: > On Wed, Jun 06, 2007 at 08:29:14PM +0200, Sam Ravnborg wrote: > > #define FUNCTION(name) .type name, %function > > Introducing this simple macro in the generic ARM codebase would > > bring down the diff significantly > > We have such a macro already - ENDPROC(). Recently introduced, > we should probably make more use of it. Took a short look at include/linux/linkage.h There is also ENTRY() that seems resonable to introduce. And btw. if arm in any way could benefit from using @function it is obvious why we should not split it up. Becasue this pathset did only add @function for one architecture. Sam ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 0/9] Thumb-2 ISA kernel port 2007-06-06 21:10 ` Sam Ravnborg @ 2007-06-06 21:19 ` Catalin Marinas 2007-06-06 22:04 ` Russell King - ARM Linux 2007-06-06 22:01 ` Russell King - ARM Linux 1 sibling, 1 reply; 8+ messages in thread From: Catalin Marinas @ 2007-06-06 21:19 UTC (permalink / raw) To: Sam Ravnborg; +Cc: Russell King - ARM Linux, linux-arch, linux-arm-kernel On Wed, 2007-06-06 at 23:10 +0200, Sam Ravnborg wrote: > On Wed, Jun 06, 2007 at 09:47:49PM +0100, Russell King - ARM Linux wrote: > > On Wed, Jun 06, 2007 at 08:29:14PM +0200, Sam Ravnborg wrote: > > > #define FUNCTION(name) .type name, %function > > > Introducing this simple macro in the generic ARM codebase would > > > bring down the diff significantly > > > > We have such a macro already - ENDPROC(). Recently introduced, > > we should probably make more use of it. > Took a short look at include/linux/linkage.h > There is also ENTRY() that seems resonable to introduce. The problem is that ENTRY is not used for functions only (I tried this initially). The linker needs to know which .globl object is a function because the Thumb-2 function addresses used in branch instructions have bit 0 set (even if the address is 2 bytes aligned). -- Catalin ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 0/9] Thumb-2 ISA kernel port 2007-06-06 21:19 ` Catalin Marinas @ 2007-06-06 22:04 ` Russell King - ARM Linux 0 siblings, 0 replies; 8+ messages in thread From: Russell King - ARM Linux @ 2007-06-06 22:04 UTC (permalink / raw) To: Catalin Marinas; +Cc: Sam Ravnborg, linux-arch, linux-arm-kernel On Wed, Jun 06, 2007 at 10:19:07PM +0100, Catalin Marinas wrote: > On Wed, 2007-06-06 at 23:10 +0200, Sam Ravnborg wrote: > > On Wed, Jun 06, 2007 at 09:47:49PM +0100, Russell King - ARM Linux wrote: > > > On Wed, Jun 06, 2007 at 08:29:14PM +0200, Sam Ravnborg wrote: > > > > #define FUNCTION(name) .type name, %function > > > > Introducing this simple macro in the generic ARM codebase would > > > > bring down the diff significantly > > > > > > We have such a macro already - ENDPROC(). Recently introduced, > > > we should probably make more use of it. > > Took a short look at include/linux/linkage.h > > There is also ENTRY() that seems resonable to introduce. > > The problem is that ENTRY is not used for functions only (I tried this > initially). The linker needs to know which .globl object is a function > because the Thumb-2 function addresses used in branch instructions have > bit 0 set (even if the address is 2 bytes aligned). Not suggesting we change ENTRY - that'd be bad. Just add the relevant sprinkling of END and ENDPROC statements in the assembly code (which will add the .size for everything, and .type for functions.) As I say, for existing ARM support it's merely cosmetic which is why there isn't a rush to do it yet, but if it's needed for T2 there's no reason not to. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 0/9] Thumb-2 ISA kernel port 2007-06-06 21:10 ` Sam Ravnborg 2007-06-06 21:19 ` Catalin Marinas @ 2007-06-06 22:01 ` Russell King - ARM Linux 1 sibling, 0 replies; 8+ messages in thread From: Russell King - ARM Linux @ 2007-06-06 22:01 UTC (permalink / raw) To: Sam Ravnborg; +Cc: Catalin Marinas, linux-arch, linux-arm-kernel On Wed, Jun 06, 2007 at 11:10:42PM +0200, Sam Ravnborg wrote: > On Wed, Jun 06, 2007 at 09:47:49PM +0100, Russell King - ARM Linux wrote: > > On Wed, Jun 06, 2007 at 08:29:14PM +0200, Sam Ravnborg wrote: > > > #define FUNCTION(name) .type name, %function > > > Introducing this simple macro in the generic ARM codebase would > > > bring down the diff significantly > > > > We have such a macro already - ENDPROC(). Recently introduced, > > we should probably make more use of it. > Took a short look at include/linux/linkage.h > There is also ENTRY() that seems resonable to introduce. > > And btw. if arm in any way could benefit from using @function > it is obvious why we should not split it up. Becasue this pathset > did only add @function for one architecture. The advantage is purely cosmetic for non-T2 ARM - it means that objdump knows whether to disassemble stuff as code or data, which makes its output very much easier to read. Since it is merely cosmetic for non-T2, I've not been in a rush to produce patches for it, but I've no objection to applying any such patches during a merge window. (I do have some open coded .type's scattered around which should also be cleaned up at the same time, particularly the head and entry code.) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 0/9] Thumb-2 ISA kernel port 2007-06-06 18:29 ` [RFC PATCH 0/9] Thumb-2 ISA kernel port Sam Ravnborg 2007-06-06 20:47 ` Russell King - ARM Linux @ 2007-06-06 22:02 ` Catalin Marinas 2007-06-07 21:05 ` Ralf Baechle 2 siblings, 0 replies; 8+ messages in thread From: Catalin Marinas @ 2007-06-06 22:02 UTC (permalink / raw) To: Sam Ravnborg; +Cc: linux-arch, linux-arm-kernel On Wed, 2007-06-06 at 20:29 +0200, Sam Ravnborg wrote: > Can you please share with us the strong arguments why another (third) > arm architecture are needed? Well, it's not a strong argument but Thumb-2 is a different instruction set. Even though there is a unified assembly language which tries to reduce/eliminate the gap between ARM and Thumb, there are still differences and, probably the most important, older toolchains don't support it. > Browsing through your patches there seems to be a common pattern: > 1) Adding a bit more info to many assembler function > 2) Small modifications to assembler function > 3) Almost replaced assembler functions > 4) Simpler Kconfig and Makefile > > > 1) Could be solved in trivial ways using a few macros. > One example: > .type printhex8, %function Yes, this is needed so that the linker knows that the address of printhex8 should have bit 1 set and also generate BL instead of BLX instructions. Adding this to the ARM code is harmless anyway (and I think we should probably do it anyway). As Russell said, there is a macro already for this. > 2) For some parts it looked like: > "We can do this different so lets do it different" > I am rather ARM assembler ignorant so that may not hold true. ^^^^^^^^^^^^^^^^^^^^^^ Indeed, it doesn't hold true :-). I tried to modify as little as possible but see the Thumb-2 limitations in my original post for why it isn't possible to use the existing code (not all variants of ldm/stm, ldr/str, different model for exception return etc.). > 3) Factor these out in separate files. For those which are completely re-written, it makes sense to move them to separate files. > 4) Short term win. The maintenance will be much simpler avoiding > the cleanup. It didn't make sense to keep all the config options for platforms that would never run Thumb-2 code. > As you are introducing a new architecture I have added linux-arch > to list of receivers - maybe someone there has more to say. I think these patches are in a too early stage at the moment to cc linux-arch and, if we decide not to go on this route (separate arch), only discussing on linux-arm-kernel would be enough. -- Catalin ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 0/9] Thumb-2 ISA kernel port 2007-06-06 18:29 ` [RFC PATCH 0/9] Thumb-2 ISA kernel port Sam Ravnborg 2007-06-06 20:47 ` Russell King - ARM Linux 2007-06-06 22:02 ` Catalin Marinas @ 2007-06-07 21:05 ` Ralf Baechle 2 siblings, 0 replies; 8+ messages in thread From: Ralf Baechle @ 2007-06-07 21:05 UTC (permalink / raw) To: Sam Ravnborg; +Cc: Catalin Marinas, linux-arch, linux-arm-kernel On Wed, Jun 06, 2007 at 08:29:14PM +0200, Sam Ravnborg wrote: > > Because of the issues listed below, merging the Thumb-2 support into > > the existing arch/arm files would clutter the existing code with > > macros like ARM, THUMB or W (for conditional compilation and the wide > > instruction format). The IT instruction is also not recognised by > > older toolchains and additional (assembler) macros would be needed, > > including support for the inline assembly. I therefore decided to > > create a separate arch/arm_t2 directory that shares a lot of code with > > the existing arch/arm. > > Hi Catalin. > Can you please share with us the strong arguments why another (third) > arm architecture are needed? It's been my experience with 64-bit MIPS that starting off with a 2nd arch then eventually factoring out the differences and unifying things back into a single mips architecture was actually the easier road to go. Downside: this approach takes long term careful coding. It is hell with the kind of "code once and resuse never" style that's only too common in the embedded industry. Ralf ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2007-06-08 11:11 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20070606172409.6689.26641.stgit@localhost.localdomain>
2007-06-06 18:29 ` [RFC PATCH 0/9] Thumb-2 ISA kernel port Sam Ravnborg
2007-06-06 20:47 ` Russell King - ARM Linux
2007-06-06 21:10 ` Sam Ravnborg
2007-06-06 21:19 ` Catalin Marinas
2007-06-06 22:04 ` Russell King - ARM Linux
2007-06-06 22:01 ` Russell King - ARM Linux
2007-06-06 22:02 ` Catalin Marinas
2007-06-07 21:05 ` Ralf Baechle
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).