[U-Boot-Users] PPC970FX 64-bit processor
U-Boot is running as a 64-bit binary on the IBM-970FX (PPC64 CPU arch), on one of Marvell evaluation boards (Pythagoras family)!!!
Some of the *NEW* components I've added to U-Boot: /include/asm-ppc64, /include/ppc970, /include/ppc64_asm.tmpl, /cpu/ppc970, /lib_ppc64
I want to add 64-bit support to some of the *COMMON* files, starting with cmd_mem.c. The commands are followed with [.b, .w, .l] represents display option: 8-bit, 16-bit, and 32-bit, accordingly. Will it be ok to change it to [.b, .s, .w, .l] for 8, 16, 32, and 64? If it is not acceptable what do you suggest? new cmd_mem64.c? other?
Regards, Tzachi Perelstein
In 64-bit mode both 'long' and 'long long' types are 8 bytes. Therefore I think that [.l] and [.ll] is not good enough for 64-bit users. I can be even more explicitly and suggest [.8, .16, .32, .64]. What do you think?
On Mon, Jan 10, 2005 at 05:12:28PM +0200, Tzachi Perelstein wrote:
Will it be ok to change it to [.b, .s, .w, .l] for 8, 16, 32, and 64? If it is not acceptable what do you suggest? new cmd_mem64.c? other?
I know I'm old-fashioned, but how about "[.b, .w, .l, .ll]"?
In message 200501101551.j0AFpOAq025585@il.marvell.com you wrote:
In 64-bit mode both 'long' and 'long long' types are 8 bytes. Therefore I think that [.l] and [.ll] is not good enough for 64-bit users. I can be even more explicitly and suggest [.8, .16, .32, .64]. What do you think?
Too much typing, and not backwards compatible.
Best regards,
Wolfgang Denk
It would break compatibility with existing scripts and documentation of everyone else. I think we should maintain earlier definitions at least for existing 32-bit implementations.
Best regards, Tolunay
John W. Linville wrote:
On Mon, Jan 10, 2005 at 05:53:11PM +0200, tzachi perelstein wrote:
I can be even more explicitly and suggest [.8, .16, .32, .64]. What do you think?
I think I like that even better.
John
The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
John W. Linville wrote:
On Mon, Jan 10, 2005 at 05:53:11PM +0200, tzachi perelstein wrote:
I can be even more explicitly and suggest [.8, .16, .32, .64]. What do you think?
I think I like that even better.
On Mon, Jan 10, 2005 at 05:09:59PM -0600, Tolunay Orkun wrote:
It would break compatibility with existing scripts and documentation of everyone else. I think we should maintain earlier definitions at least for existing 32-bit implementations.
Perhaps...if that is the prevailing logic, then I think my original proposal (just adding a .ll) makes the most sense.
Still, I think the bit-width based modifiers is the cleaner solution.
Tzachi, perhaps you can #ifdef the cli code to only use the [.8, ..., .64] for new and/or 64-bit platforms?
Just a thought...
John
In message 5C4013D09582FF41833487F21C085CF991ADCE@Hqexch02.il.marvell.com you wrote:
U-Boot is running as a 64-bit binary on the IBM-970FX (PPC64 CPU arch), on one of Marvell evaluation boards (Pythagoras family)!!!
Congratulations!!!!
I want to add 64-bit support to some of the *COMMON* files, starting with cmd_mem.c. The commands are followed with [.b, .w, .l] represents display option: 8-bit, 16-bit, and 32-bit, accordingly. Will it be ok to change it to [.b, .s, .w, .l] for 8, 16, 32, and 64?
No, this is not acceptable, as it would break backwards compatibility.
If it is not acceptable what do you suggest? new cmd_mem64.c? other?
The BDI2000 telnet interface (which was one of my references for the "b" and "w" suffixes) uses "d" for "double" to access 64 bit objects. I think we should do the same and add ".d" [=> .b, .w, .l, .d].
------_=_NextPart_001_01C4F726.CC47ACA6 Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
And *please* don't post HTML to this list.
Best regards,
Wolfgang Denk
On Mon, Jan 10, 2005 at 04:45:34PM +0100, Wolfgang Denk wrote:
The BDI2000 telnet interface (which was one of my references for the "b" and "w" suffixes) uses "d" for "double" to access 64 bit objects. I think we should do the same and add ".d" [=> .b, .w, .l, .d].
That would satisfy me...
John
participants (5)
-
John W. Linville -
Tolunay Orkun -
Tzachi Perelstein -
tzachi perelstein
-
Wolfgang Denk