OpenCores

OpenCores

load pc-relative

no use

no use

1/2

Next

Last

load pc-relative by Unknown on Mar 11, 2005			Not available!
Hello, a simple question just to double check. I'm new in using the or1200 risc and I'm trying to write down my first programs in assembler. I noticed that there is no availability of load instruction (from memory) that allows to use a PC-realtive address: Rd <- [PC + #imm] It sounds strange to me that is instruction has not been foreseen into the ISA. Could you confirm that this instruction doesn't exist or if there is a trick to do the same using only one ASM instruction? Thanks Stefano Hello, a simple question just to double check. I'm new in using the or1200 risc and I'm trying to write down my first programs in assembler. I noticed that there is no availability of load instruction (from memory) that allows to use a PC-realtive address: Rd It sounds strange to me that is instruction has not been foreseen into the ISA. Could you confirm that this instruction doesn't exist or if there is a trick to do the same using only one ASM instruction? Thanks Stefano

load pc-relative by Unknown on Mar 11, 2005			Not available!
[q] Hello, a simple question just to double check. I'm new in using the or1200 risc and I'm trying to write down my first programs in assembler. I noticed that there is no availability of load instruction (from memory) that allows to use a PC-realtive address: Rd <- [PC + #imm] It sounds strange to me that is instruction has not been foreseen into the ISA. Could you confirm that this instruction doesn't exist or if there is a trick to do the same using only one ASM instruction?[/q] You can do that with the SPR_NPC register, something like the following (you have to #include "spr_defs.h" somewere prior to this code. You can pick up an spr_defs.h file from or1ksim/or1k/spr_defs.h): l.mfspr r3,r0,SPR_NPC l.lwz r4,4(r3) l.nop 0 Which will load the l.nop 0 instruction. This only works in superviser mode though. You can also do some magic with l.jal that also works in usermode. Something like this: l.jal 2 l.nop 0 l.lwz r4,4(r9) l.nop 0 Which will also load the second l.nop 0 instruction. You explicitly said `only one ASM instruction' does that mean that you want to avoid too much typeing or where you implying `only one openrisc instruction' (you know that in other assemblers you get pseudo instruction, that may translate into more instructions...)? Since this is your first program in or1200, I have to ask: What are you trying to do that you must use pc relative addresses? Not haveing done much asm programing myself, I just can't imagine what problem pc-relative addressing is meant to solve... nog. Hello, a simple question just to double check. I'm new in using the or1200 risc and I'm trying to write down my first programs in assembler. I noticed that there is no availability of load instruction (from memory) that allows to use a PC-realtive address: Rd It sounds strange to me that is instruction has not been foreseen into the ISA. Could you confirm that this instruction doesn't exist or if there is a trick to do the same using only one ASM instruction? You can do that with the SPR_NPC register, something like the following (you have to #include "spr_defs.h" somewere prior to this code. You can pick up an spr_defs.h file from or1ksim/or1k/spr_defs.h): l.mfspr r3,r0,SPR_NPC l.lwz r4,4(r3) l.nop 0 Which will load the l.nop 0 instruction. This only works in superviser mode though. You can also do some magic with l.jal that also works in usermode. Something like this: l.jal 2 l.nop 0 l.lwz r4,4(r9) l.nop 0 Which will also load the second l.nop 0 instruction. You explicitly said `only one ASM instruction' does that mean that you want to avoid too much typeing or where you implying `only one openrisc instruction' (you know that in other assemblers you get pseudo instruction, that may translate into more instructions...)? Since this is your first program in or1200, I have to ask: What are you trying to do that you must use pc relative addresses? Not haveing done much asm programing myself, I just can't imagine what problem pc-relative addressing is meant to solve... nog.

load pc-relative by Unknown on Mar 11, 2005			Not available!
[q] l.mfspr r3,r0,SPR_NPC l.lwz r4,4(r3) l.nop 0[/q] As a matter of fact this is wrong. It appears that the code should be: l.mfspr r3,r0,SPR_NPC l.lwz r4,8(r3) l.nop 0 Though I do have a question to the people that designed the architecture (Damjan?): The architechture manual just says about NPC: `the address instruction just to be executed'. Other than the gramatical error that `of the' is missing, it is not clear what the results of the instruction `l.mfspr r3,r0,SPR_NPC' is. By the time NPC is read, the l.mfspr instruction is in full execution which, according to the above quote, would make NPC point to the next instruction that has not YET been executed, which then should be the address of the instruction that comes after the l.mfspr instruction but that is not what the simulator does. Which is correct? Either way, this should be noted somewere in the manual. I have attached a little test program that I have written to test the behaviour of the NPC/PPC registers. There is one more question I have with regard to the NPC/PPC handleing (Copied from my test program): /* FIXME: Exactly what's meant to be in ppc? After a system call * exception it is evident that the caller should know that a syscall * occured and not mess with the PPC but what happens if the exception * is an ITLB/DTLB miss? The architechture manual doesn't clarify this. * You just can't (easily) anticipate when an exception of this kind may * or may not occur. For PPC handling the simulator implements the * behaviour that is tested here ie. the PPC points to the l.rfe * instruction / nog. l.mfspr r3,r0,SPR_NPC l.lwz r4,4(r3) l.nop 0 As a matter of fact this is wrong. It appears that the code should be: l.mfspr r3,r0,SPR_NPC l.lwz r4,8(r3) l.nop 0 Though I do have a question to the people that designed the architecture (Damjan?): The architechture manual just says about NPC: `the address instruction just to be executed'. Other than the gramatical error that `of the' is missing, it is not clear what the results of the instruction `l.mfspr r3,r0,SPR_NPC' is. By the time NPC is read, the l.mfspr instruction is in full execution which, according to the above quote, would make NPC point to the next instruction that has not YET been executed, which then should be the address of the instruction that comes after the l.mfspr instruction but that is not what the simulator does. Which is correct? Either way, this should be noted somewere in the manual. I have attached a little test program that I have written to test the behaviour of the NPC/PPC registers. There is one more question I have with regard to the NPC/PPC handleing (Copied from my test program): / FIXME: Exactly what's meant to be in ppc? After a system call * exception it is evident that the caller should know that a syscall * occured and not mess with the PPC but what happens if the exception * is an ITLB/DTLB miss? The architechture manual doesn't clarify this. * You just can't (easily) anticipate when an exception of this kind may * or may not occur. For PPC handling the simulator implements the * behaviour that is tested here ie. the PPC points to the l.rfe * instruction */ nog.

load pc-relative by Unknown on Mar 11, 2005			Not available!
[q] There was a good reason - which I can't remember right now - why NPC / PPC SPRs have been added to SPRs. However there is a bunch of problems when talking about the PC. What is a PC? Is this a register which points to a next (or current) instruction? What happens if you have superscalar microarchitecture. You might execute several instructions in the same clock cycle - how many PCs you have there? So PC is more of a concept (because even the superscalar microarchitectures ar sequential machines in concept). In fact there really isn't any PC register in HW ! Really important - Do not use access to NPC and PPC. The NPC / PPC SPRs should probably not be documented, or probably better explicitly denied access in the arch manual. For some reason I can't remember why these two registers were added. But trust me, there was a good reason... I think they were used in the or1200 testing when some SW was written and these SPRs were documented in the arch manual... I'll make a remark in the arch manual not to use these two SPRs in any normal SW code.[/q] I thought that the expalation would be something like that. A comment in the manual is really needed. While we are on the subject of makeing corrections to the arch manual, I have a couple more (Note that I'm reading the pdf version): 1) The contents page says all sections start on page 6! (Not a big issue really). 2) The l.ff1 instruction format says that it takes 3 operands (l.ff1 rD,rA,rB), while its description only talks about two (rD and rA). I assume that the description is correct. 3) The l.maci instruction format talks about l.maci rB, I. While it's description talks about rA. Again, I assume that the description is correct. 4) The l.maci/l.mac/l.msb instructions state that the operands are first multiplied then truncated to 32-bits and only then added to MACLO/MACHI but in the simulater the truncation never happens and the mac tests (testbench/mul) depend on the non truncated behaviour. Which is correct? 5) How is the system call exception meant to be handeld if the l.sys instruction is in a delay slot? The arch manual says that the EPCR points to the jump instruction, which is ok. Then when time comes to do a l.rfe, execution would return to the jump instruction, the delay slot instruction (l.sys) executed again, and so everything will deadlock. Is the system call handler meant to handle this situation somehow? I can't think of a good way to do this except to go into laborius instruction decoding and emulating. The easy way out of this is just deny an l.sys instruction from apearing in a delay-slot. nog. There was a good reason - which I can't remember right now - why NPC / PPC SPRs have been added to SPRs. However there is a bunch of problems when talking about the PC. What is a PC? Is this a register which points to a next (or current) instruction? What happens if you have superscalar microarchitecture. You might execute several instructions in the same clock cycle - how many PCs you have there? So PC is more of a concept (because even the superscalar microarchitectures ar sequential machines in concept). In fact there really isn't any PC register in HW ! Really important - Do not use access to NPC and PPC. The NPC / PPC SPRs should probably not be documented, or probably better explicitly denied access in the arch manual. For some reason I can't remember why these two registers were added. But trust me, there was a good reason... I think they were used in the or1200 testing when some SW was written and these SPRs were documented in the arch manual... I'll make a remark in the arch manual not to use these two SPRs in any normal SW code. I thought that the expalation would be something like that. A comment in the manual is really needed. While we are on the subject of makeing corrections to the arch manual, I have a couple more (Note that I'm reading the pdf version): 1) The contents page says all sections start on page 6! (Not a big issue really). 2) The l.ff1 instruction format says that it takes 3 operands (l.ff1 rD,rA,rB), while its description only talks about two (rD and rA). I assume that the description is correct. 3) The l.maci instruction format talks about l.maci rB, I. While it's description talks about rA. Again, I assume that the description is correct. 4) The l.maci/l.mac/l.msb instructions state that the operands are first multiplied then truncated to 32-bits and only then added to MACLO/MACHI but in the simulater the truncation never happens and the mac tests (testbench/mul) depend on the non truncated behaviour. Which is correct? 5) How is the system call exception meant to be handeld if the l.sys instruction is in a delay slot? The arch manual says that the EPCR points to the jump instruction, which is ok. Then when time comes to do a l.rfe, execution would return to the jump instruction, the delay slot instruction (l.sys) executed again, and so everything will deadlock. Is the system call handler meant to handle this situation somehow? I can't think of a good way to do this except to go into laborius instruction decoding and emulating. The easy way out of this is just deny an l.sys instruction from apearing in a delay-slot. nog.

load pc-relative by Unknown on Mar 11, 2005			Not available!
There was a good reason - which I can't remember right now - why NPC / PPC SPRs have been added to SPRs. However there is a bunch of problems when talking about the PC. What is a PC? Is this a register which points to a next (or current) instruction? What happens if you have superscalar microarchitecture. You might execute several instructions in the same clock cycle - how many PCs you have there? So PC is more of a concept (because even the superscalar microarchitectures ar sequential machines in concept). In fact there really isn't any PC register in HW ! Really important - Do not use access to NPC and PPC. The NPC / PPC SPRs should probably not be documented, or probably better explicitly denied access in the arch manual. For some reason I can't remember why these two registers were added. But trust me, there was a good reason... I think they were used in the or1200 testing when some SW was written and these SPRs were documented in the arch manual... I'll make a remark in the arch manual not to use these two SPRs in any normal SW code. Anyway the proper way how a programmer, especially in user code, should be able to get the content of the "PC". It is using the l.jal or l.jalr instructions. This is the only proper way. For example how to do it in 2 insns: l.xxx /* your code... / l.jal cont / jump to cont - save l.jal's address to link register / cont: l.or rD,r9,r0 / move "PC" from link register to rD, accidently this is also the delay slot insn / l.xxx / your code... / regards, Damjan PS However I'm going to answer Nog's question anyway: NPC points to "mfspr" instruction and "PPC" points to an instruction preceeding the mfspr instruction. ----- Original Message ----- From: "GyÃ¶rgy 'nog' Jeney" <<A HREF="mailto:nog@sdf.lonestar.org">nog@sdf.lonestar.org</A>> To: "List about OpenRISC project" <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Friday, March 11, 2005 6:18 PM Subject: Re: [openrisc] load pc-relative [q] l.mfspr r3,r0,SPR_NPC l.lwz r4,4(r3) l.nop 0[/q] As a matter of fact this is wrong. It appears that the code should be: l.mfspr r3,r0,SPR_NPC l.lwz r4,8(r3) l.nop 0 Though I do have a question to the people that designed the architecture (Damjan?): The architechture manual just says about NPC: `the address instruction just to be executed'. Other than the gramatical error that `of the' is missing, it is not clear what the results of the instruction `l.mfspr r3,r0,SPR_NPC' is. By the time NPC is read, the l.mfspr instruction is in full execution which, according to the above quote, would make NPC point to the next instruction that has not YET been executed, which then should be the address of the instruction that comes after the l.mfspr instruction but that is not what the simulator does. Which is correct? Either way, this should be noted somewere in the manual. I have attached a little test program that I have written to test the behaviour of the NPC/PPC registers. There is one more question I have with regard to the NPC/PPC handleing (Copied from my test program): / FIXME: Exactly what's meant to be in ppc? After a system call * exception it is evident that the caller should know that a syscall * occured and not mess with the PPC but what happens if the exception * is an ITLB/DTLB miss? The architechture manual doesn't clarify this. * You just can't (easily) anticipate when an exception of this kind may * or may not occur. For PPC handling the simulator implements the * behaviour that is tested here ie. the PPC points to the l.rfe * instruction / nog. _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> [/q] There was a good reason - which I can't remember right now - why NPC / PPC SPRs have been added to SPRs. However there is a bunch of problems when talking about the PC. What is a PC? Is this a register which points to a next (or current) instruction? What happens if you have superscalar microarchitecture. You might execute several instructions in the same clock cycle - how many PCs you have there? So PC is more of a concept (because even the superscalar microarchitectures ar sequential machines in concept). In fact there really isn't any PC register in HW ! Really important - Do not use access to NPC and PPC. The NPC / PPC SPRs should probably not be documented, or probably better explicitly denied access in the arch manual. For some reason I can't remember why these two registers were added. But trust me, there was a good reason... I think they were used in the or1200 testing when some SW was written and these SPRs were documented in the arch manual... I'll make a remark in the arch manual not to use these two SPRs in any normal SW code. Anyway the proper way how a programmer, especially in user code, should be able to get the content of the "PC". It is using the l.jal or l.jalr instructions. This is the only proper way. For example how to do it in 2 insns: l.xxx / your code... / l.jal cont / jump to cont - save l.jal's address to link register / cont: l.or rD,r9,r0 / move "PC" from link register to rD, accidently this is also the delay slot insn / l.xxx / your code... / regards, Damjan PS However I'm going to answer Nog's question anyway: NPC points to "mfspr" instruction and "PPC" points to an instruction preceeding the mfspr instruction. ----- Original Message ----- From: "GyÃ¶rgy 'nog' Jeney" nog@sdf.lonestar.org> To: "List about OpenRISC project" openrisc@opencores.org> Sent: Friday, March 11, 2005 6:18 PM Subject: Re: [openrisc] load pc-relative l.mfspr r3,r0,SPR_NPC l.lwz r4,4(r3) l.nop 0 As a matter of fact this is wrong. It appears that the code should be: l.mfspr r3,r0,SPR_NPC l.lwz r4,8(r3) l.nop 0 Though I do have a question to the people that designed the architecture (Damjan?): The architechture manual just says about NPC: `the address instruction just to be executed'. Other than the gramatical error that `of the' is missing, it is not clear what the results of the instruction `l.mfspr r3,r0,SPR_NPC' is. By the time NPC is read, the l.mfspr instruction is in full execution which, according to the above quote, would make NPC point to the next instruction that has not YET been executed, which then should be the address of the instruction that comes after the l.mfspr instruction but that is not what the simulator does. Which is correct? Either way, this should be noted somewere in the manual. I have attached a little test program that I have written to test the behaviour of the NPC/PPC registers. There is one more question I have with regard to the NPC/PPC handleing (Copied from my test program): / FIXME: Exactly what's meant to be in ppc? After a system call * exception it is evident that the caller should know that a syscall * occured and not mess with the PPC but what happens if the exception * is an ITLB/DTLB miss? The architechture manual doesn't clarify this. * You just can't (easily) anticipate when an exception of this kind may * or may not occur. For PPC handling the simulator implements the * behaviour that is tested here ie. the PPC points to the l.rfe * instruction */ nog. _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

load pc-relative by Unknown on Mar 11, 2005			Not available!
Actually if you want "PC of the l.jal" instruction, you'll have to subtract 8 from the R9. But if you are satisfied with the "PC of the l.or/l.addi" you don't have to subtract anything. So if you subtract, just replace l.or with l.addi for example like this: l.xxx /* your code... / l.jal cont / jump to cont - save l.jal's address +8 to link register / cont: l.addi rD,r9,-8 / move "PC" from link register to rD, accidently this is also the delay slot insn / l.xxx / your code... / regards, Damjan Actually if you want "PC of the l.jal" instruction, you'll have to subtract 8 from the R9. But if you are satisfied with the "PC of the l.or/l.addi" you don't have to subtract anything. So if you subtract, just replace l.or with l.addi for example like this: l.xxx / your code... / l.jal cont / jump to cont - save l.jal's address +8 to link register / cont: l.addi rD,r9,-8 / move "PC" from link register to rD, accidently this is also the delay slot insn / l.xxx / your code... */ regards, Damjan

load pc-relative by Unknown on Mar 11, 2005			Not available!
[q] Simple. l.sys should not be used in a delay slot. l.sys is considered like any other jump instruction. Jump instructions should not be used in a delay slot - if they are the results are undefined. I'll add a note in the description.[/q] That's what I thought. Then on page 251, the rubrik that corisponds to l.sys (and probably l.trap) should have a hughe N/A (Not Aplicable) in them, instead of a confusing description that is irrelevent. nog. Simple. l.sys should not be used in a delay slot. l.sys is considered like any other jump instruction. Jump instructions should not be used in a delay slot - if they are the results are undefined. I'll add a note in the description. That's what I thought. Then on page 251, the rubrik that corisponds to l.sys (and probably l.trap) should have a hughe N/A (Not Aplicable) in them, instead of a confusing description that is irrelevent. nog.

load pc-relative by Unknown on Mar 11, 2005			Not available!
[q] btw if you have time, you can make corrections yourself. You have to modify the <A HREF="http://www.opencores.org/cvsweb.shtml/or1k/gen_or1k_isa/sources/or1k_isadesc.h">http://www.opencores.org/cvsweb.shtml/or1k/gen_or1k_isa/sources/or1k_isadesc.h</A> Please make sure you take the latest version from the cvs. Once you are done, just commit it back to the cvs. Maybe someone else has found some discrepancies, now would be a good time to report them in order to incorporate corrections in the next release of the arch manual. When I make a new revision of the arch manual, I just generate insn descriptions from the or1k_isadesc.h file.[/q] Ok, I'll submit some patches then. I thought that the arch manual simply a word document and gen_or1k_isa just generated the simple format of the instructions, and since I have no tools to manipulate word documents I figured I'll just report them here. nog. btw if you have time, you can make corrections yourself. You have to modify the http://www.opencores.org/cvsweb.shtml/or1k/gen_or1k_isa/sources/or1k_isadesc.h Please make sure you take the latest version from the cvs. Once you are done, just commit it back to the cvs. Maybe someone else has found some discrepancies, now would be a good time to report them in order to incorporate corrections in the next release of the arch manual. When I make a new revision of the arch manual, I just generate insn descriptions from the or1k_isadesc.h file. Ok, I'll submit some patches then. I thought that the arch manual simply a word document and gen_or1k_isa just generated the simple format of the instructions, and since I have no tools to manipulate word documents I figured I'll just report them here. nog.

load pc-relative by Unknown on Mar 11, 2005			Not available!
It seems I'm getting real tired now, I also wanted to say: [q] Actually the problem here is because in the past both were used (in some prehistoric applications of or1200). We'll have to decide on just one. I'd say the one without truncation is correct.[/q] If the application is really `prehistoric' then there is no reason to keep mention of the old behaviour. The `new' behaviour is more acurate and I believe that should the correct one. It would probably be best to decide on the behaviour that the rtl follows (now that it is cast in silicone...). I also just noticed that the description of l.macrc says that the low 32-bits are returned in rD, but or1ksim returns bits [60:28]. This behaviour is really strange to me so I guess the arch manual is correct once again. [q]> Simple. l.sys should not be used in a delay slot. l.sys is considered like > any other jump instruction. Jump instructions should not be used in a delay > slot - if they are the results are undefined. I'll add a note in the > description.[/q] That's what I thought. Then on page 251, the rubrik that corisponds to l.sys (and probably l.trap) should have a hughe N/A (Not Aplicable) in them, instead of a confusing description that is irrelevent.[/q] I meant to say that the rubrik that corissponds to l.sys in the delay slot.... nog (who hopes he won't follow up with corrections to his own posts again). It seems I'm getting real tired now, I also wanted to say: Actually the problem here is because in the past both were used (in some prehistoric applications of or1200). We'll have to decide on just one. I'd say the one without truncation is correct. If the application is really `prehistoric' then there is no reason to keep mention of the old behaviour. The `new' behaviour is more acurate and I believe that should the correct one. It would probably be best to decide on the behaviour that the rtl follows (now that it is cast in silicone...). I also just noticed that the description of l.macrc says that the low 32-bits are returned in rD, but or1ksim returns bits [60:28]. This behaviour is really strange to me so I guess the arch manual is correct once again. > Simple. l.sys should not be used in a delay slot. l.sys is considered like > any other jump instruction. Jump instructions should not be used in a delay > slot - if they are the results are undefined. I'll add a note in the > description. That's what I thought. Then on page 251, the rubrik that corisponds to l.sys (and probably l.trap) should have a hughe N/A (Not Aplicable) in them, instead of a confusing description that is irrelevent. I meant to say that the rubrik that corissponds to l.sys in the delay slot.... nog (who hopes he won't follow up with corrections to his own posts again).

load pc-relative by Unknown on Mar 11, 2005			Not available!
[q] 2) The l.ff1 instruction format says that it takes 3 operands (l.ff1 rD,rA,rB), while its description only talks about two (rD and rA). I assume that the description is correct.[/q] Description is correct. [q] 3) The l.maci instruction format talks about l.maci rB, I. While it's description talks about rA. Again, I assume that the description is correct.[/q] Desc is correct. [q] 4) The l.maci/l.mac/l.msb instructions state that the operands are first multiplied then truncated to 32-bits and only then added to MACLO/MACHI but in the simulater the truncation never happens and the mac tests (testbench/mul) depend on the non truncated behaviour. Which is correct? [/q] Actually the problem here is because in the past both were used (in some prehistoric applications of or1200). We'll have to decide on just one. I'd say the one without truncation is correct. [q] 5) How is the system call exception meant to be handeld if the l.sys instruction is in a delay slot? The arch manual says that the EPCR points to the jump[/q] Simple. l.sys should not be used in a delay slot. l.sys is considered like any other jump instruction. Jump instructions should not be used in a delay slot - if they are the results are undefined. I'll add a note in the description. regards, Damjan 2) The l.ff1 instruction format says that it takes 3 operands (l.ff1 rD,rA,rB), while its description only talks about two (rD and rA). I assume that the description is correct. Description is correct. 3) The l.maci instruction format talks about l.maci rB, I. While it's description talks about rA. Again, I assume that the description is correct. Desc is correct. 4) The l.maci/l.mac/l.msb instructions state that the operands are first multiplied then truncated to 32-bits and only then added to MACLO/MACHI but in the simulater the truncation never happens and the mac tests (testbench/mul) depend on the non truncated behaviour. Which is correct? Actually the problem here is because in the past both were used (in some prehistoric applications of or1200). We'll have to decide on just one. I'd say the one without truncation is correct. 5) How is the system call exception meant to be handeld if the l.sys instruction is in a delay slot? The arch manual says that the EPCR points to the jump Simple. l.sys should not be used in a delay slot. l.sys is considered like any other jump instruction. Jump instructions should not be used in a delay slot - if they are the results are undefined. I'll add a note in the description. regards, Damjan

load pc-relative by Unknown on Mar 11, 2005			Not available!
Nog btw if you have time, you can make corrections yourself. You have to modify the <A HREF="http://www.opencores.org/cvsweb.shtml/or1k/gen_or1k_isa/sources/or1k_isadesc.h">http://www.opencores.org/cvsweb.shtml/or1k/gen_or1k_isa/sources/or1k_isadesc.h</A> Please make sure you take the latest version from the cvs. Once you are done, just commit it back to the cvs. Maybe someone else has found some discrepancies, now would be a good time to report them in order to incorporate corrections in the next release of the arch manual. When I make a new revision of the arch manual, I just generate insn descriptions from the or1k_isadesc.h file. regards, Damjan ----- Original Message ----- From: "Damjan Lampret" <<A HREF="mailto:damjanl@opencores.org">damjanl@opencores.org</A>> To: "List about OpenRISC project" <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Friday, March 11, 2005 8:43 PM Subject: Re: [openrisc] load pc-relative [q]> 2) The l.ff1 instruction format says that it takes 3 operands (l.ff1 rD,rA,rB), while its description only talks about two (rD and rA). I assume that the description is correct.[/q] Description is correct. [q] 3) The l.maci instruction format talks about l.maci rB, I. While it's description talks about rA. Again, I assume that the description is correct.[/q] Desc is correct. [q] 4) The l.maci/l.mac/l.msb instructions state that the operands are first multiplied then truncated to 32-bits and only then added to MACLO/MACHI but in the simulater the truncation never happens and the mac tests (testbench/mul) depend on the non truncated behaviour. Which is correct? [/q] Actually the problem here is because in the past both were used (in some prehistoric applications of or1200). We'll have to decide on just one. I'd say the one without truncation is correct. [q] 5) How is the system call exception meant to be handeld if the l.sys instruction is in a delay slot? The arch manual says that the EPCR points to the jump[/q] Simple. l.sys should not be used in a delay slot. l.sys is considered like any other jump instruction. Jump instructions should not be used in a delay slot - if they are the results are undefined. I'll add a note in the description. regards, Damjan _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A> [/q] Nog btw if you have time, you can make corrections yourself. You have to modify the http://www.opencores.org/cvsweb.shtml/or1k/gen_or1k_isa/sources/or1k_isadesc.h Please make sure you take the latest version from the cvs. Once you are done, just commit it back to the cvs. Maybe someone else has found some discrepancies, now would be a good time to report them in order to incorporate corrections in the next release of the arch manual. When I make a new revision of the arch manual, I just generate insn descriptions from the or1k_isadesc.h file. regards, Damjan ----- Original Message ----- From: "Damjan Lampret" damjanl@opencores.org> To: "List about OpenRISC project" openrisc@opencores.org> Sent: Friday, March 11, 2005 8:43 PM Subject: Re: [openrisc] load pc-relative > 2) The l.ff1 instruction format says that it takes 3 operands (l.ff1 rD,rA,rB), while its description only talks about two (rD and rA). I assume that the description is correct. Description is correct. 3) The l.maci instruction format talks about l.maci rB, I. While it's description talks about rA. Again, I assume that the description is correct. Desc is correct. 4) The l.maci/l.mac/l.msb instructions state that the operands are first multiplied then truncated to 32-bits and only then added to MACLO/MACHI but in the simulater the truncation never happens and the mac tests (testbench/mul) depend on the non truncated behaviour. Which is correct? Actually the problem here is because in the past both were used (in some prehistoric applications of or1200). We'll have to decide on just one. I'd say the one without truncation is correct. 5) How is the system call exception meant to be handeld if the l.sys instruction is in a delay slot? The arch manual says that the EPCR points to the jump Simple. l.sys should not be used in a delay slot. l.sys is considered like any other jump instruction. Jump instructions should not be used in a delay slot - if they are the results are undefined. I'll add a note in the description. regards, Damjan _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

load pc-relative by Unknown on Mar 12, 2005			Not available!
Hi Nog, thanks for your comments. I answer to your qustion explaining a bit better waht I'm doing. My need is to have an or1200 processor version as little as possible, comsuming few ram for my appliaction. I already customized the processor avoiding MAC and multipliar usage. Also the banck of registers has been reduced to 16 registers only. Further optimizations will come if needed. On top of that I was evaluating the possiblity to introduce a decompression mechanism to the or1200 that, starting from an instruction set built on 16bit only, allows to translate on the fly such ISA to the native OR1200 ISA (32bit). Pratically speaking the same mechanism that ARM has introduced in its processors (Thumb mode). I'm convinced that in case of OR1200 we could gain 30-40% of the code size (performance are not the main target in my case). In order to implement such mechansim I could invent a new ISA based on 16bit but, after, I would need a new tools chain to develop SW, hence ... to many time to be spent (.. and also too difficult for me) To go faster I tought to translate the ARM Thumb code ISA into the OR1200 ISA but this easy only if I found a one-by-one replacemente of each ARM Thumb ISA into the OR1200 ISA. After a first screenning I noticed that 95% of the ARM instructions could be remapped but there are some of them that would require more then one OR1200 instruction: one of these is the load with PC-relative address in fact. I tryied to write down a simple ASM program for the OR1200 implementing such PC-relative addressing but I didn't find a way but using more then one instruction (as you are confirming). Since I'm not a SW specialist and it is the first time I use OR1200 assembler I prefferred to ask to the forum for a confirmation. This is the full story .... (sorry to be tedious). Stefano [q]-- Messaggio originale -- Date: Fri, 11 Mar 2005 17:12:24 +0100 From: "GyÃ¶rgy 'nog' Jeney" <<A HREF="mailto:nog@sdf.lonestar.org">nog@sdf.lonestar.org</A>> To: List about OpenRISC project <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Subject: Re: [openrisc] load pc-relative Reply-To: List about OpenRISC project <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> [q] Hello, a simple question just to double check. I'm new in using the or1200 risc and I'm trying to write down my first programs in assembler. I noticed that there is no availability of load instruction (from memory) that allows to use a PC-realtive address: Rd <- [PC + #imm] It sounds strange to me that is instruction has not been foreseen into the ISA. Could you confirm that this instruction doesn't exist or if there is[/q] a [q] trick to do the same using only one ASM instruction?[/q] You can do that with the SPR_NPC register, something like the following[/q] (you [q]have to #include "spr_defs.h" somewere prior to this code. You can pick up an spr_defs.h file from or1ksim/or1k/spr_defs.h): l.mfspr r3,r0,SPR_NPC l.lwz r4,4(r3) l.nop 0 Which will load the l.nop 0 instruction. This only works in superviser[/q] mode [q]though. You can also do some magic with l.jal that also works in usermode. Something like this: l.jal 2 l.nop 0 l.lwz r4,4(r9) l.nop 0 Which will also load the second l.nop 0 instruction. You explicitly said `only one ASM instruction' does that mean that you want to avoid too much typeing or where you implying `only one openrisc instruction' (you know that in other assemblers you get pseudo instruction, that may translate into more instructions...)? Since this is your first program in or1200, I have to ask: What are you trying to do that you must use pc relative addresses? Not[/q] haveing [q]done much asm programing myself, I just can't imagine what problem pc-relative addressing is meant to solve... nog. _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A>[/q] Hi Nog, thanks for your comments. I answer to your qustion explaining a bit better waht I'm doing. My need is to have an or1200 processor version as little as possible, comsuming few ram for my appliaction. I already customized the processor avoiding MAC and multipliar usage. Also the banck of registers has been reduced to 16 registers only. Further optimizations will come if needed. On top of that I was evaluating the possiblity to introduce a decompression mechanism to the or1200 that, starting from an instruction set built on 16bit only, allows to translate on the fly such ISA to the native OR1200 ISA (32bit). Pratically speaking the same mechanism that ARM has introduced in its processors (Thumb mode). I'm convinced that in case of OR1200 we could gain 30-40% of the code size (performance are not the main target in my case). In order to implement such mechansim I could invent a new ISA based on 16bit but, after, I would need a new tools chain to develop SW, hence ... to many time to be spent (.. and also too difficult for me) To go faster I tought to translate the ARM Thumb code ISA into the OR1200 ISA but this easy only if I found a one-by-one replacemente of each ARM Thumb ISA into the OR1200 ISA. After a first screenning I noticed that 95% of the ARM instructions could be remapped but there are some of them that would require more then one OR1200 instruction: one of these is the load with PC-relative address in fact. I tryied to write down a simple ASM program for the OR1200 implementing such PC-relative addressing but I didn't find a way but using more then one instruction (as you are confirming). Since I'm not a SW specialist and it is the first time I use OR1200 assembler I prefferred to ask to the forum for a confirmation. This is the full story .... (sorry to be tedious). Stefano -- Messaggio originale -- Date: Fri, 11 Mar 2005 17:12:24 +0100 From: "GyÃ¶rgy 'nog' Jeney" nog@sdf.lonestar.org> To: List about OpenRISC project openrisc@opencores.org> Subject: Re: [openrisc] load pc-relative Reply-To: List about OpenRISC project openrisc@opencores.org> Hello, a simple question just to double check. I'm new in using the or1200 risc and I'm trying to write down my first programs in assembler. I noticed that there is no availability of load instruction (from memory) that allows to use a PC-realtive address: Rd It sounds strange to me that is instruction has not been foreseen into the ISA. Could you confirm that this instruction doesn't exist or if there is a trick to do the same using only one ASM instruction? You can do that with the SPR_NPC register, something like the following (you have to #include "spr_defs.h" somewere prior to this code. You can pick up an spr_defs.h file from or1ksim/or1k/spr_defs.h): l.mfspr r3,r0,SPR_NPC l.lwz r4,4(r3) l.nop 0 Which will load the l.nop 0 instruction. This only works in superviser mode though. You can also do some magic with l.jal that also works in usermode. Something like this: l.jal 2 l.nop 0 l.lwz r4,4(r9) l.nop 0 Which will also load the second l.nop 0 instruction. You explicitly said `only one ASM instruction' does that mean that you want to avoid too much typeing or where you implying `only one openrisc instruction' (you know that in other assemblers you get pseudo instruction, that may translate into more instructions...)? Since this is your first program in or1200, I have to ask: What are you trying to do that you must use pc relative addresses? Not haveing done much asm programing myself, I just can't imagine what problem pc-relative addressing is meant to solve... nog. _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

load pc-relative by Unknown on Mar 13, 2005			Not available!
* <A HREF="mailto:stefano.lorenzini1@tin.it">stefano.lorenzini1@tin.it</A> (<A HREF="mailto:stefano.lorenzini1@tin.it">stefano.lorenzini1@tin.it</A>) wrote: [q] Hi Nog, thanks for your comments. I answer to your qustion explaining a bit better waht I'm doing. My need is to have an or1200 processor version as little as possible, comsuming few ram for my appliaction. I already customized the processor avoiding MAC and multipliar usage. Also the banck of registers has been reduced to 16 registers only. Further optimizations will come if needed. On top of that I was evaluating the possiblity to introduce a decompression mechanism to the or1200 that, starting from an instruction set built on 16bit only, allows to translate on the fly such ISA to the native OR1200 ISA (32bit). Pratically speaking the same mechanism that ARM has introduced in its processors (Thumb mode). I'm convinced that in case of OR1200 we could gain 30-40% of the code size (performance are not the main target in my case). In order to implement such mechansim I could invent a new ISA based on 16bit but, after, I would need a new tools chain to develop SW, hence ... to many time to be spent (.. and also too difficult for me) To go faster I tought to translate the ARM Thumb code ISA into the OR1200 ISA but this easy only if I found a one-by-one replacemente of each ARM Thumb ISA into the OR1200 ISA. After a first screenning I noticed that 95% of the ARM instructions could be remapped but there are some of them that would require more then one OR1200 instruction: one of these is the load with PC-relative address in fact. I tryied to write down a simple ASM program for the OR1200 implementing such PC-relative addressing but I didn't find a way but using more then one instruction (as you are confirming).[/q] Is this the only instruction you couldn't map to or1200 instructions ? (if not which are the others). I'd suggest you a deal: if you implement the mapping from ARM Thumb to or1200 ISA i'll provide you the missing instruction. best regards, p. * stefano.lorenzini1@tin.it (stefano.lorenzini1@tin.it) wrote: Hi Nog, thanks for your comments. I answer to your qustion explaining a bit better waht I'm doing. My need is to have an or1200 processor version as little as possible, comsuming few ram for my appliaction. I already customized the processor avoiding MAC and multipliar usage. Also the banck of registers has been reduced to 16 registers only. Further optimizations will come if needed. On top of that I was evaluating the possiblity to introduce a decompression mechanism to the or1200 that, starting from an instruction set built on 16bit only, allows to translate on the fly such ISA to the native OR1200 ISA (32bit). Pratically speaking the same mechanism that ARM has introduced in its processors (Thumb mode). I'm convinced that in case of OR1200 we could gain 30-40% of the code size (performance are not the main target in my case). In order to implement such mechansim I could invent a new ISA based on 16bit but, after, I would need a new tools chain to develop SW, hence ... to many time to be spent (.. and also too difficult for me) To go faster I tought to translate the ARM Thumb code ISA into the OR1200 ISA but this easy only if I found a one-by-one replacemente of each ARM Thumb ISA into the OR1200 ISA. After a first screenning I noticed that 95% of the ARM instructions could be remapped but there are some of them that would require more then one OR1200 instruction: one of these is the load with PC-relative address in fact. I tryied to write down a simple ASM program for the OR1200 implementing such PC-relative addressing but I didn't find a way but using more then one instruction (as you are confirming). Is this the only instruction you couldn't map to or1200 instructions ? (if not which are the others). I'd suggest you a deal: if you implement the mapping from ARM Thumb to or1200 ISA i'll provide you the missing instruction. best regards, p.

load pc-relative by Unknown on Mar 13, 2005			Not available!
[q] Is this the only instruction you couldn't map to or1200 instructions ? (if not which are the others). I'd suggest you a deal: if you implement the mapping from ARM Thumb to or1200 ISA i'll provide you the missing instruction.[/q] OpenRISC is its own architechture. While I agree that haveing a Thumb-style instruction set for openrisc is not a bad thing, adding instructions to the or1200 ISA just because arm has them is IMHO not a good enough reason. Like I still can't see where a load pc relative instruction (I see the same problems with this that Damjan and I discussed about the NPC spr) would be usefull I just don't see why we should bloat the or1200 ISA with a useless instruction just on the grounds that THEY have it so it must be usefull. If the designers of the openrisc architechture wanted an architechture that is basically arm, they would have implemented that architechture and not go to the pain of porting a whole toolchain, maintaining the architechture, write a simulator, etc. I don't wish to deter you from your work but we should keep in mind this little comment from kernel developer Ingo Molnar, who put it best: "The Linux acceptance process is not about "whose patch sucks least", but whether it hits a subsystem-specific bar of architectural requirements or not.... We'll rather live on with one less feature for another year than with a crappy feature that is twice as hard to get rid of!" While we aren't discussing the linux kernel, IMO this comment should be valid about the openrisc development process (except that we CAN'T get rid of crappy features...). I hope I'm not going to be taken to suggest that no more instruction should be added to the openrisc ISA, I'm just saying that there should be atleast one good (practical) reason to add an instruction and the reason posted here is not good enough (IMHO). nog. Is this the only instruction you couldn't map to or1200 instructions ? (if not which are the others). I'd suggest you a deal: if you implement the mapping from ARM Thumb to or1200 ISA i'll provide you the missing instruction. OpenRISC is its own architechture. While I agree that haveing a Thumb-style instruction set for openrisc is not a bad thing, adding instructions to the or1200 ISA just because arm has them is IMHO not a good enough reason. Like I still can't see where a load pc relative instruction (I see the same problems with this that Damjan and I discussed about the NPC spr) would be usefull I just don't see why we should bloat the or1200 ISA with a useless instruction just on the grounds that THEY have it so it must be usefull. If the designers of the openrisc architechture wanted an architechture that is basically arm, they would have implemented that architechture and not go to the pain of porting a whole toolchain, maintaining the architechture, write a simulator, etc. I don't wish to deter you from your work but we should keep in mind this little comment from kernel developer Ingo Molnar, who put it best: "The Linux acceptance process is not about "whose patch sucks least", but whether it hits a subsystem-specific bar of architectural requirements or not.... We'll rather live on with one less feature for another year than with a crappy feature that is twice as hard to get rid of!" While we aren't discussing the linux kernel, IMO this comment should be valid about the openrisc development process (except that we CAN'T get rid of crappy features...). I hope I'm not going to be taken to suggest that no more instruction should be added to the openrisc ISA, I'm just saying that there should be atleast one good (practical) reason to add an instruction and the reason posted here is not good enough (IMHO). nog.

load pc-relative by Unknown on Mar 13, 2005			Not available!
[q] Your points are valid, but i do not see how would thumb style instruction set for OpenRISC do any harm. Remember, openrisc is a softcore, and i had assumed all the time that this mode would be provided as one of the options. (like you can synthesise openrisc with or without mmu, hw. multiplication, devision and a dozen of other options).[/q] I knew I was going to get missinterpreted. I never said that a thumb style instruction set would be any harm. I'll reiterate: I don't think that adding random, useless, instructions (I'm talking about the core openrisc ones, not the thumb ones) just because others are doing it will do us any good. [q] In the end if such an approach is found useful adding one instruction (again as an option or as a costum instruction) is good IMHO, since it would allow you to reuse the complete (optimized, well proven) arm toolchain.[/q] We can `base' `our' thumb-style ISA on the arm one (ie. implement everything except the instructions that we find useless), no problem there. Ofcourse if I am really missing the point of this one instruction, feel free to enlighten me. nog. Your points are valid, but i do not see how would thumb style instruction set for OpenRISC do any harm. Remember, openrisc is a softcore, and i had assumed all the time that this mode would be provided as one of the options. (like you can synthesise openrisc with or without mmu, hw. multiplication, devision and a dozen of other options). I knew I was going to get missinterpreted. I never said that a thumb style instruction set would be any harm. I'll reiterate: I don't think that adding random, useless, instructions (I'm talking about the core openrisc ones, not the thumb ones) just because others are doing it will do us any good. In the end if such an approach is found useful adding one instruction (again as an option or as a costum instruction) is good IMHO, since it would allow you to reuse the complete (optimized, well proven) arm toolchain. We can `base' `our' thumb-style ISA on the arm one (ie. implement everything except the instructions that we find useless), no problem there. Ofcourse if I am really missing the point of this one instruction, feel free to enlighten me. nog.

no use

no use

1/2

Next

Last

© copyright 1999-2026 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.