OpenCores

OpenCores

[or1ksim #7] Stricter typeing...

no use

no use

1/1

no use

no use

[or1ksim #7] Stricter typeing... by Unknown on Jan 26, 2005			Not available!
Hi, I'm not sure how this patch shall be received but I believe this is the way to go. I have introduced 2 new types: oraddr_t and orreg_t oraddr_t is used to mark addresses that the simulated processor (and peripherals) address. This is basically a reqirement to implement a 64-bit simulator (no, I'm not going to do that anytime soon). I have also defined the formating macros for these new types (PRIxADDR and PRIxREG), (What C99 has done in inttypes.h). I realise that this header and macros may not be availible on some varients of unix, but I don't know, so if you know of a place were the simulator might be used and these types are not availible, then shout and I'll stick in a configure check to fix it. While doing all these changes I noticed that eval_direct{8,16,32} has this comment: `/* for simulator accesses, the ones that cpu wouldn't do' but in the those functions we raise an exception if the memory area is not valid. Is this really a good idea? If the cpu wouldn't do the access then there wouldn't be an exception... ChangeLog: * Mark a simulated cpu address as such, by introducing the new oraddr_t type. nog. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch7.gz Type: application/x-gunzip Size: 25434 bytes Desc: not available Url : <A HREF="http://www.opencores.org/forums/openrisc/attachments/20050126/6df83efc/patch7-0001.bin">http://www.opencores.org/forums/openrisc/attachments/20050126/6df83efc/patch7-0001.bin</A> Hi, I'm not sure how this patch shall be received but I believe this is the way to go. I have introduced 2 new types: oraddr_t and orreg_t oraddr_t is used to mark addresses that the simulated processor (and peripherals) address. This is basically a reqirement to implement a 64-bit simulator (no, I'm not going to do that anytime soon). I have also defined the formating macros for these new types (PRIxADDR and PRIxREG), (What C99 has done in inttypes.h). I realise that this header and macros may not be availible on some varients of unix, but I don't know, so if you know of a place were the simulator might be used and these types are not availible, then shout and I'll stick in a configure check to fix it. While doing all these changes I noticed that eval_direct{8,16,32} has this comment: `/* for simulator accesses, the ones that cpu wouldn't do' but in the those functions we raise an exception if the memory area is not valid. Is this really a good idea? If the cpu wouldn't do the access then there wouldn't be an exception... ChangeLog: * Mark a simulated cpu address as such, by introducing the new oraddr_t type. nog. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch7.gz Type: application/x-gunzip Size: 25434 bytes Desc: not available Url : http://www.opencores.org/forums/openrisc/attachments/20050126/6df83efc/patch7-0001.bin

[or1ksim #7] Stricter typeing... by Unknown on Jan 26, 2005			Not available!
[q]> oraddr_t is used to mark addresses that the simulated processor (and > peripherals) address. This is basically a reqirement to implement a 64-bit > simulator (no, I'm not going to do that anytime soon). I have also defined the > formating macros for these new types (PRIxADDR and PRIxREG), (What C99 has done > in inttypes.h). I realise that this header and macros may not be availible on > some varients of unix, but I don't know, so if you know of a place were the > simulator might be used and these types are not availible, then shout and I'll > stick in a configure check to fix it.[/q] Simulator should buid at least on Linux, Solaris, Cygwin and FreeBSD. I do not think there is a need to introduce any constructs that would further restrict the or1ksim portability....[/q] Would it suffice if I fixed the sim to compile and work if `inttypes.h' is not availible on the host system, or should I just drop this set of changes? Do you actually know that this will break on Solaris/FreeBSD or Cygwin? I just have this feeling that it will but I don't want to introduce hughe amounts of useless configure magic for nothing. nog. > oraddr_t is used to mark addresses that the simulated processor (and > peripherals) address. This is basically a reqirement to implement a 64-bit > simulator (no, I'm not going to do that anytime soon). I have also defined the > formating macros for these new types (PRIxADDR and PRIxREG), (What C99 has done > in inttypes.h). I realise that this header and macros may not be availible on > some varients of unix, but I don't know, so if you know of a place were the > simulator might be used and these types are not availible, then shout and I'll > stick in a configure check to fix it. Simulator should buid at least on Linux, Solaris, Cygwin and FreeBSD. I do not think there is a need to introduce any constructs that would further restrict the or1ksim portability.... Would it suffice if I fixed the sim to compile and work if `inttypes.h' is not availible on the host system, or should I just drop this set of changes? Do you actually know that this will break on Solaris/FreeBSD or Cygwin? I just have this feeling that it will but I don't want to introduce hughe amounts of useless configure magic for nothing. nog.

[or1ksim #7] Stricter typeing... by Unknown on Jan 26, 2005			Not available!
[q]> oraddr_t is used to mark addresses that the simulated processor (and > peripherals) address. This is basically a reqirement to implement a 64-bit > simulator (no, I'm not going to do that anytime soon). I have also defined the > formating macros for these new types (PRIxADDR and PRIxREG), (What C99 has done > in inttypes.h). I realise that this header and macros may not be availible on > some varients of unix, but I don't know, so if you know of a place were the > simulator might be used and these types are not availible, then shout and I'll > stick in a configure check to fix it.[/q] Simulator should buid at least on Linux, Solaris, Cygwin and FreeBSD. I do not think there is a need to introduce any constructs that would further restrict the or1ksim portability....[/q] Would it suffice if I fixed the sim to compile and work if `inttypes.h' is not availible on the host system, or should I just drop this set of changes? Do you actually know that this will break on Solaris/FreeBSD or Cygwin? I just have this feeling that it will but I don't want to introduce hughe amounts of useless configure magic for nothing. nog. > oraddr_t is used to mark addresses that the simulated processor (and > peripherals) address. This is basically a reqirement to implement a 64-bit > simulator (no, I'm not going to do that anytime soon). I have also defined the > formating macros for these new types (PRIxADDR and PRIxREG), (What C99 has done > in inttypes.h). I realise that this header and macros may not be availible on > some varients of unix, but I don't know, so if you know of a place were the > simulator might be used and these types are not availible, then shout and I'll > stick in a configure check to fix it. Simulator should buid at least on Linux, Solaris, Cygwin and FreeBSD. I do not think there is a need to introduce any constructs that would further restrict the or1ksim portability.... Would it suffice if I fixed the sim to compile and work if `inttypes.h' is not availible on the host system, or should I just drop this set of changes? Do you actually know that this will break on Solaris/FreeBSD or Cygwin? I just have this feeling that it will but I don't want to introduce hughe amounts of useless configure magic for nothing. nog.

[or1ksim #7] Stricter typeing... by Unknown on Jan 26, 2005			Not available!
* GyÃ¶rgy 'nog' Jeney (<A HREF="mailto:nog@sdf.lonestar.org">nog@sdf.lonestar.org</A>) wrote: [q] Hi, I'm not sure how this patch shall be received but I believe this is the way to go. I have introduced 2 new types: oraddr_t and orreg_t oraddr_t is used to mark addresses that the simulated processor (and peripherals) address. This is basically a reqirement to implement a 64-bit simulator (no, I'm not going to do that anytime soon). I have also defined the formating macros for these new types (PRIxADDR and PRIxREG), (What C99 has done in inttypes.h). I realise that this header and macros may not be availible on some varients of unix, but I don't know, so if you know of a place were the simulator might be used and these types are not availible, then shout and I'll stick in a configure check to fix it.[/q] Simulator should buid at least on Linux, Solaris, Cygwin and FreeBSD. I do not think there is a need to introduce any constructs that would further restrict the or1ksim portability.... [q] While doing all these changes I noticed that eval_direct{8,16,32} has this comment: `/* for simulator accesses, the ones that cpu wouldn't do' but in the those functions we raise an exception if the memory area is not valid. Is this really a good idea? If the cpu wouldn't do the access then there wouldn't be an exception...[/q] Those should never happen. I agree, it would be better if i changed the the text to something "WARNING..." The thing is that i introduced the direct functions to fix the statistics and also enforce the same behaviour when dumping to log file. So i left those instructions there since i wasn't sure that some other part of simulator didn't rely on those instructions. (it is possible that internal simulator access happens in the same cycle but before the actual 'architectural' access. in this case the code there is correct but really ugly....) the best thing would be to just print an error there and exit the simulator, but i have this feeling it will break... [q] ChangeLog: Mark a simulated cpu address as such, by introducing the new oraddr_t type. nog.[/q] best regards, p. * GyÃ¶rgy 'nog' Jeney (nog@sdf.lonestar.org) wrote: Hi, I'm not sure how this patch shall be received but I believe this is the way to go. I have introduced 2 new types: oraddr_t and orreg_t oraddr_t is used to mark addresses that the simulated processor (and peripherals) address. This is basically a reqirement to implement a 64-bit simulator (no, I'm not going to do that anytime soon). I have also defined the formating macros for these new types (PRIxADDR and PRIxREG), (What C99 has done in inttypes.h). I realise that this header and macros may not be availible on some varients of unix, but I don't know, so if you know of a place were the simulator might be used and these types are not availible, then shout and I'll stick in a configure check to fix it. Simulator should buid at least on Linux, Solaris, Cygwin and FreeBSD. I do not think there is a need to introduce any constructs that would further restrict the or1ksim portability.... While doing all these changes I noticed that eval_direct{8,16,32} has this comment: `/* for simulator accesses, the ones that cpu wouldn't do' but in the those functions we raise an exception if the memory area is not valid. Is this really a good idea? If the cpu wouldn't do the access then there wouldn't be an exception... Those should never happen. I agree, it would be better if i changed the the text to something "WARNING..." The thing is that i introduced the direct functions to fix the statistics and also enforce the same behaviour when dumping to log file. So i left those instructions there since i wasn't sure that some other part of simulator didn't rely on those instructions. (it is possible that internal simulator access happens in the same cycle but before the actual 'architectural' access. in this case the code there is correct but really ugly....) the best thing would be to just print an error there and exit the simulator, but i have this feeling it will break... ChangeLog: Mark a simulated cpu address as such, by introducing the new oraddr_t type. nog. best regards, p.

[or1ksim #7] Stricter typeing... by Unknown on Jan 27, 2005			Not available!
[q] why not just copy the required definitions from inttypes.h (or maybe even the whole file) and convince configure to use those if it can't find the native one installed on system. there isn't much behind these macros... /* UPPERCASE hexadecimal notation. / # define PRIX8 "X" # define PRIX16 "X" # define PRIX32 "X" # define PRIX64 __PRI64_PREFIX "X"[/q] That's what I meant with `fix configure'. I think I'll use the official definitions they are availible and fall back to our (not yet existing) ones. I'll send an updated patch. nog. why not just copy the required definitions from inttypes.h (or maybe even the whole file) and convince configure to use those if it can't find the native one installed on system. there isn't much behind these macros... / UPPERCASE hexadecimal notation. */ # define PRIX8 "X" # define PRIX16 "X" # define PRIX32 "X" # define PRIX64 __PRI64_PREFIX "X" That's what I meant with `fix configure'. I think I'll use the official definitions they are availible and fall back to our (not yet existing) ones. I'll send an updated patch. nog.

[or1ksim #7] Stricter typeing... by Unknown on Jan 27, 2005			Not available!
* GyÃ¶rgy 'nog' Jeney (<A HREF="mailto:nog@sdf.lonestar.org">nog@sdf.lonestar.org</A>) wrote: [q] > oraddr_t is used to mark addresses that the simulated processor (and > peripherals) address. This is basically a reqirement to implement a 64-bit > simulator (no, I'm not going to do that anytime soon). I have also defined the > formating macros for these new types (PRIxADDR and PRIxREG), (What C99 has done > in inttypes.h). I realise that this header and macros may not be availible on > some varients of unix, but I don't know, so if you know of a place were the > simulator might be used and these types are not availible, then shout and I'll > stick in a configure check to fix it.[/q] > > Simulator should buid at least on Linux, Solaris, Cygwin and FreeBSD. I > do not think there is a need to introduce any constructs > that would further restrict the or1ksim portability....[/q] Would it suffice if I fixed the sim to compile and work if `inttypes.h' is not availible on the host system, or should I just drop this set of changes? Do you actually know that this will break on Solaris/FreeBSD or Cygwin? I just have this feeling that it will but I don't want to introduce hughe amounts of useless configure magic for nothing.[/q] why not just copy the required definitions from inttypes.h (or maybe even the whole file) and convince configure to use those if it can't find the native one installed on system. there isn't much behind these macros... /* UPPERCASE hexadecimal notation. / # define PRIX8 "X" # define PRIX16 "X" # define PRIX32 "X" # define PRIX64 __PRI64_PREFIX "X" best regards, p. GyÃ¶rgy 'nog' Jeney (nog@sdf.lonestar.org) wrote: > oraddr_t is used to mark addresses that the simulated processor (and > peripherals) address. This is basically a reqirement to implement a 64-bit > simulator (no, I'm not going to do that anytime soon). I have also defined the > formating macros for these new types (PRIxADDR and PRIxREG), (What C99 has done > in inttypes.h). I realise that this header and macros may not be availible on > some varients of unix, but I don't know, so if you know of a place were the > simulator might be used and these types are not availible, then shout and I'll > stick in a configure check to fix it. > > Simulator should buid at least on Linux, Solaris, Cygwin and FreeBSD. I > do not think there is a need to introduce any constructs > that would further restrict the or1ksim portability.... Would it suffice if I fixed the sim to compile and work if `inttypes.h' is not availible on the host system, or should I just drop this set of changes? Do you actually know that this will break on Solaris/FreeBSD or Cygwin? I just have this feeling that it will but I don't want to introduce hughe amounts of useless configure magic for nothing. why not just copy the required definitions from inttypes.h (or maybe even the whole file) and convince configure to use those if it can't find the native one installed on system. there isn't much behind these macros... /* UPPERCASE hexadecimal notation. */ # define PRIX8 "X" # define PRIX16 "X" # define PRIX32 "X" # define PRIX64 __PRI64_PREFIX "X" best regards, p.

[or1ksim #7] Stricter typeing... by Unknown on Jan 28, 2005			Not available!
[q]> why not just copy the required definitions from inttypes.h (or maybe > even the whole file) and convince configure to use those if it can't > find the native one installed on system. there isn't much behind these > macros... > > /* UPPERCASE hexadecimal notation. / > # define PRIX8 "X" > # define PRIX16 "X" > # define PRIX32 "X" > # define PRIX64 __PRI64_PREFIX "X"[/q] That's what I meant with `fix configure'. I think I'll use the official definitions they are availible and fall back to our (not yet existing) ones. I'll send an updated patch.[/q] Here's the updated patch. I have removed the extras subdirectory. It is really a badly chosen name. There are no `extras' in there only `ports' of functions that are not availible everywere, so I have renamed it to `port', the name given in some other projects. I have also moved the isblank `port' from cpu/common/parse.c to port/isblank.c, where it belongs. I have also added the printf attribute to the debug function, so gcc also checks the format strings passed to that function. ChangeLog: Mark a simulated cpu address as such, by introducing the new oraddr_t type. nog. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch7.gz Type: application/x-gunzip Size: 32725 bytes Desc: not available Url : <A HREF="http://www.opencores.org/forums/openrisc/attachments/20050128/ec3dc5be/patch7-0001.bin">http://www.opencores.org/forums/openrisc/attachments/20050128/ec3dc5be/patch7-0001.bin</A> > why not just copy the required definitions from inttypes.h (or maybe > even the whole file) and convince configure to use those if it can't > find the native one installed on system. there isn't much behind these > macros... > > /* UPPERCASE hexadecimal notation. / > # define PRIX8 "X" > # define PRIX16 "X" > # define PRIX32 "X" > # define PRIX64 __PRI64_PREFIX "X" That's what I meant with `fix configure'. I think I'll use the official definitions they are availible and fall back to our (not yet existing) ones. I'll send an updated patch. Here's the updated patch. I have removed the extras subdirectory. It is really a badly chosen name. There are no `extras' in there only `ports' of functions that are not availible everywere, so I have renamed it to `port', the name given in some other projects. I have also moved the isblank `port' from cpu/common/parse.c to port/isblank.c, where it belongs. I have also added the printf attribute to the debug function, so gcc also checks the format strings passed to that function. ChangeLog: Mark a simulated cpu address as such, by introducing the new oraddr_t type. nog. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch7.gz Type: application/x-gunzip Size: 32725 bytes Desc: not available Url : http://www.opencores.org/forums/openrisc/attachments/20050128/ec3dc5be/patch7-0001.bin

[or1ksim #7] Stricter typeing... by Unknown on Jan 29, 2005			Not available!
Hi, * GyÃ¶rgy 'nog' Jeney (<A HREF="mailto:nog@sdf.lonestar.org">nog@sdf.lonestar.org</A>) wrote: [q] > why not just copy the required definitions from inttypes.h (or maybe > even the whole file) and convince configure to use those if it can't > find the native one installed on system. there isn't much behind these > macros... > > /* UPPERCASE hexadecimal notation. / > # define PRIX8 "X" > # define PRIX16 "X" > # define PRIX32 "X" > # define PRIX64 __PRI64_PREFIX "X"[/q] > > That's what I meant with `fix configure'. I think I'll use the official > definitions they are availible and fall back to our (not yet existing) ones. > I'll send an updated patch.[/q] Here's the updated patch. I have removed the extras subdirectory. It is really a badly chosen name. There are no `extras' in there only `ports' of functions that are not availible everywere, so I have renamed it to `port', the name given in some other projects. I have also moved the isblank `port' from cpu/common/parse.c to port/isblank.c, where it belongs. I have also added the printf attribute to the debug function, so gcc also checks the format strings passed to that function. ChangeLog: Mark a simulated cpu address as such, by introducing the new oraddr_t type.[/q] I'm generaly ok with the patch though it needs some corrections. This is not entirely ok (yes it will work for now, but if we do stricter typing why not do it right ;) INSTRUCTION (l_sll) { - unsigned long temp1; + uint32_t temp1; The register size for this instruction is 64-bit on 64-bit architecture. So this shoult be of orreg_t ... (the same applies to other insns) Oh and the genexec.c file should be removed from cvs (or at least reneamed) because it breaks the out-of-tree builds. Besides that, the whole toolchain build & works ... best regards, p. Hi, * GyÃ¶rgy 'nog' Jeney (nog@sdf.lonestar.org) wrote: > why not just copy the required definitions from inttypes.h (or maybe > even the whole file) and convince configure to use those if it can't > find the native one installed on system. there isn't much behind these > macros... > > /* UPPERCASE hexadecimal notation. / > # define PRIX8 "X" > # define PRIX16 "X" > # define PRIX32 "X" > # define PRIX64 __PRI64_PREFIX "X" > > That's what I meant with `fix configure'. I think I'll use the official > definitions they are availible and fall back to our (not yet existing) ones. > I'll send an updated patch. Here's the updated patch. I have removed the extras subdirectory. It is really a badly chosen name. There are no `extras' in there only `ports' of functions that are not availible everywere, so I have renamed it to `port', the name given in some other projects. I have also moved the isblank `port' from cpu/common/parse.c to port/isblank.c, where it belongs. I have also added the printf attribute to the debug function, so gcc also checks the format strings passed to that function. ChangeLog: Mark a simulated cpu address as such, by introducing the new oraddr_t type. I'm generaly ok with the patch though it needs some corrections. This is not entirely ok (yes it will work for now, but if we do stricter typing why not do it right ;) INSTRUCTION (l_sll) { - unsigned long temp1; + uint32_t temp1; The register size for this instruction is 64-bit on 64-bit architecture. So this shoult be of orreg_t ... (the same applies to other insns) Oh and the genexec.c file should be removed from cvs (or at least reneamed) because it breaks the out-of-tree builds. Besides that, the whole toolchain build & works ... best regards, p.

[or1ksim #7] Stricter typeing... by Unknown on Jan 29, 2005			Not available!
[q] I'm generaly ok with the patch though it needs some corrections. This is not entirely ok (yes it will work for now, but if we do stricter typing why not do it right ;) INSTRUCTION (l_sll) { - unsigned long temp1; + uint32_t temp1; The register size for this instruction is 64-bit on 64-bit architecture. So this shoult be of orreg_t ... (the same applies to other insns)[/q] Fixed. I forgot to mention that you have to manually rerun aclocal && automake && autoconf, before configureing your tree (Because of the new port/ directory). I have also changed the orreg_t type to be signed and intruduced a new uorreg_t type as an unsigned register. ChangeLog: * Mark a simulated cpu address as such, by introducing the new oraddr_t type. nog. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch7.gz Type: application/x-gunzip Size: 32767 bytes Desc: not available Url : <A HREF="http://www.opencores.org/forums/openrisc/attachments/20050129/afac2fba/patch7-0001.bin">http://www.opencores.org/forums/openrisc/attachments/20050129/afac2fba/patch7-0001.bin</A> I'm generaly ok with the patch though it needs some corrections. This is not entirely ok (yes it will work for now, but if we do stricter typing why not do it right ;) INSTRUCTION (l_sll) { - unsigned long temp1; + uint32_t temp1; The register size for this instruction is 64-bit on 64-bit architecture. So this shoult be of orreg_t ... (the same applies to other insns) Fixed. I forgot to mention that you have to manually rerun aclocal && automake && autoconf, before configureing your tree (Because of the new port/ directory). I have also changed the orreg_t type to be signed and intruduced a new uorreg_t type as an unsigned register. ChangeLog: * Mark a simulated cpu address as such, by introducing the new oraddr_t type. nog. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch7.gz Type: application/x-gunzip Size: 32767 bytes Desc: not available Url : http://www.opencores.org/forums/openrisc/attachments/20050129/afac2fba/patch7-0001.bin

no use

no use

1/1

no use

no use

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