One more idea that just popped up (I promise I won't spam the list too much with this kind of junk).
How much of a performance penalty/loss would be incurred by "pulling a Transmeta" -- by which I mean emulating x86 hardware with, in this case, ARM...? Say, convincing an A20 to emulate something like a P3 CPU?
The idea comes from the Transmeta Crusoe CPU -- which is NOT x86 at all! It's something I'm really unfamiliar with called VLIW, and it has what amounts to a software emulation layer between it and the rest of the system, so that it can run x86 code. Of course that incurs an INSANE amount of overhead, because the CPU is basically doing its job twice -- translating the instructions and then executing them. It's a remarkable kludge if you ask me, but it works.
ICT designed the loongson it's MIPS with hardware-assist acceleration/translation of the 200 most popular x86 instructions. it gets 70% the speed of an x86 CPU. transmeta was extreme-end of that scale, sadly went belly-up.
l.
On 10/22/2013 9:49 PM, luke.leighton wrote:
ICT designed the loongson it's MIPS with hardware-assist acceleration/translation of the 200 most popular x86 instructions. it gets 70% the speed of an x86 CPU. transmeta was extreme-end of that scale, sadly went belly-up.
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
Well, that sucks for Transmeta I guess...
Slightly better idea -- since IIRC the final version of the initial CPU Card will be using a dual-core A20... how about using one core for the emulation part and the other for execution...? That would speed things up a little as well, because there'd be at least a "sort-of" hardware pre-processor setup that way.
On 10/22/2013 09:55 PM, Christopher Havel wrote:
On 10/22/2013 9:49 PM, luke.leighton wrote:
ICT designed the loongson it's MIPS with hardware-assist acceleration/translation of the 200 most popular x86 instructions. it gets 70% the speed of an x86 CPU. transmeta was extreme-end of that scale, sadly went belly-up.
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
Well, that sucks for Transmeta I guess...
Slightly better idea -- since IIRC the final version of the initial CPU Card will be using a dual-core A20... how about using one core for the emulation part and the other for execution...? That would speed things up a little as well, because there'd be at least a "sort-of" hardware pre-processor setup that way.
It's easy to suggest idea's, what's more powerful is providing an open platform on which those that are passionate about those ideas can build on. I feel luke has set the right base line goals of simply getting GPL respecting hardware into the hands of developers. From there true innovation can happen in the hands of hundreds instead of the limited few that are currently shepherding the seeds of EOMA-68 ecosystem.
For the short term, let's keep our eyes on the prize. That prize being a large scale run of cards on which revenue can be made and invested in furthering the EOMA-68 ecosystem.
On Wed, Oct 23, 2013 at 3:36 AM, Scott Sullivan scott@ss.org wrote:
On 10/22/2013 09:55 PM, Christopher Havel wrote:
On 10/22/2013 9:49 PM, luke.leighton wrote:
ICT designed the loongson it's MIPS with hardware-assist acceleration/translation of the 200 most popular x86 instructions. it gets 70% the speed of an x86 CPU. transmeta was extreme-end of that scale, sadly went belly-up.
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
Well, that sucks for Transmeta I guess...
Slightly better idea -- since IIRC the final version of the initial CPU Card will be using a dual-core A20... how about using one core for the emulation part and the other for execution...? That would speed things up a little as well, because there'd be at least a "sort-of" hardware pre-processor setup that way.
It's easy to suggest idea's, what's more powerful is providing an open platform on which those that are passionate about those ideas can build on.
in other words, exactly these kinds of things can be explored, christopher, by others including yourself. it's not *our* place as suppliers of the hardware to "dictate" what it *shall* be used for.
I feel luke has set the right base line goals of simply getting GPL respecting hardware into the hands of developers. From there true innovation can happen in the hands of hundreds instead of the limited few that are currently shepherding the seeds of EOMA-68 ecosystem.
!!!
For the short term, let's keep our eyes on the prize. That prize being a large scale run of cards on which revenue can be made and invested in furthering the EOMA-68 ecosystem.
... what scott said!!
On 10/23/2013 03:52 AM, luke.leighton wrote:
On Wed, Oct 23, 2013 at 3:36 AM, Scott Sullivan scott@ss.org wrote:
On 10/22/2013 09:55 PM, Christopher Havel wrote:
Slightly better idea -- since IIRC the final version of the initial CPU Card will be using a dual-core A20... how about using one core for the emulation part and the other for execution...? That would speed things up a little as well, because there'd be at least a "sort-of" hardware pre-processor setup that way.
It's easy to suggest idea's, what's more powerful is providing an open platform on which those that are passionate about those ideas can build on.
in other words, exactly these kinds of things can be explored, christopher, by others including yourself. it's not *our* place as suppliers of the hardware to "dictate" what it *shall* be used for.
Christopher,
Because ideas like these are dependant on the cards being available, by the time those are ready, they can get forgotten if left on the mailing list. I think it would be worth adding this suggestion to the community ideas page of the wiki. That way you and other developers can come back and review it once there are EOMA-68 card in more folks hands.
http://rhombus-tech.net/community_ideas/
I feel luke has set the right base line goals of simply getting GPL respecting hardware into the hands of developers. From there true innovation can happen in the hands of hundreds instead of the limited few that are currently shepherding the seeds of EOMA-68 ecosystem.
!!!
For the short term, let's keep our eyes on the prize. That prize being a large scale run of cards on which revenue can be made and invested in furthering the EOMA-68 ecosystem.
... what scott said!!
Indeed, but make note of the long term dreams that make this venture so compelling.
On 10/23/2013 9:25 AM, Scott Sullivan wrote:
On 10/23/2013 03:52 AM, luke.leighton wrote:
On Wed, Oct 23, 2013 at 3:36 AM, Scott Sullivan scott@ss.org wrote:
On 10/22/2013 09:55 PM, Christopher Havel wrote:
Slightly better idea -- since IIRC the final version of the initial CPU Card will be using a dual-core A20... how about using one core for the emulation part and the other for execution...? That would speed things up a little as well, because there'd be at least a "sort-of" hardware pre-processor setup that way.
It's easy to suggest idea's, what's more powerful is providing an open platform on which those that are passionate about those ideas can build on.
in other words, exactly these kinds of things can be explored, christopher, by others including yourself. it's not *our* place as suppliers of the hardware to "dictate" what it *shall* be used for.
Christopher,
Because ideas like these are dependant on the cards being available, by the time those are ready, they can get forgotten if left on the mailing list. I think it would be worth adding this suggestion to the community ideas page of the wiki. That way you and other developers can come back and review it once there are EOMA-68 card in more folks hands.
http://rhombus-tech.net/community_ideas/
I feel luke has set the right base line goals of simply getting GPL respecting hardware into the hands of developers. From there true innovation can happen in the hands of hundreds instead of the limited few that are currently shepherding the seeds of EOMA-68 ecosystem.
!!!
For the short term, let's keep our eyes on the prize. That prize being a large scale run of cards on which revenue can be made and invested in furthering the EOMA-68 ecosystem.
... what scott said!!
Indeed, but make note of the long term dreams that make this venture so compelling.
I added my idea to the list at the other end of that link. I've never edited a wiki page before *redface* so I hope I did it right...
Hello,
On Tue, 22 Oct 2013 13:41:49 -0400 Christopher Havel laserhawk64@gmail.com wrote:
One more idea that just popped up (I promise I won't spam the list too much with this kind of junk).
How much of a performance penalty/loss would be incurred by "pulling a Transmeta" -- by which I mean emulating x86 hardware with, in this case, ARM...? Say, convincing an A20 to emulate something like a P3 CPU?
One thing you forgot to mention is why the heck someone would want to emulate x86? Where someone needs x86, they just use it, in all other areas, everyone is galloping away from x86 and uses raw performance of platform, without need to "emulate" anything. Anyway, QEMU emulates anything on anything, so what?
+++ Paul Sokolovsky [2013-10-23 19:58 +0300]:
Hello,
On Tue, 22 Oct 2013 13:41:49 -0400 Christopher Havel laserhawk64@gmail.com wrote:
One more idea that just popped up (I promise I won't spam the list too much with this kind of junk).
How much of a performance penalty/loss would be incurred by "pulling a Transmeta" -- by which I mean emulating x86 hardware with, in this case, ARM...? Say, convincing an A20 to emulate something like a P3 CPU?
One thing you forgot to mention is why the heck someone would want to emulate x86? Where someone needs x86, they just use it, in all other areas, everyone is galloping away from x86 and uses raw performance of platform, without need to "emulate" anything. Anyway, QEMU emulates anything on anything, so what?
Quite. We have this functionality already and it's as simple as: apt-get install qemu-system-x86
Not sure if debian has packaged the statically-linked version whch lets you run random foreign binaries in chroots, but that's a small matter.
Wookey
Hello,
On Wed, 23 Oct 2013 19:25:05 +0100 Wookey wookey@wookware.org wrote:
+++ Paul Sokolovsky [2013-10-23 19:58 +0300]:
Hello,
On Tue, 22 Oct 2013 13:41:49 -0400 Christopher Havel laserhawk64@gmail.com wrote:
One more idea that just popped up (I promise I won't spam the list too much with this kind of junk).
How much of a performance penalty/loss would be incurred by "pulling a Transmeta" -- by which I mean emulating x86 hardware with, in this case, ARM...? Say, convincing an A20 to emulate something like a P3 CPU?
One thing you forgot to mention is why the heck someone would want to emulate x86? Where someone needs x86, they just use it, in all other areas, everyone is galloping away from x86 and uses raw performance of platform, without need to "emulate" anything. Anyway, QEMU emulates anything on anything, so what?
Quite. We have this functionality already and it's as simple as: apt-get install qemu-system-x86
Not sure if debian has packaged the statically-linked version whch lets you run random foreign binaries in chroots, but that's a small matter.
Do you mean qemu-user-x86? That lacks futex() implementation so wouldn't run anything more or less interesting... But yep, fixing that would be a good task for someone young and ambitious to learn to hack ;-).
Wookey
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/
On 10/23/2013 02:37 PM, Paul Sokolovsky wrote:
Quite. We have this functionality already and it's as simple as: apt-get install qemu-system-x86
Not sure if debian has packaged the statically-linked version whch lets you run random foreign binaries in chroots, but that's a small matter.
Do you mean qemu-user-x86? That lacks futex() implementation so wouldn't run anything more or less interesting... But yep, fixing that would be a good task for someone young and ambitious to learn to hack ;-).
$ > ./fix-exclusive-for-inclusive good task for _anyone_ ambitious to learn to hack.
On 10/23/2013 2:54 PM, Scott Sullivan wrote:
On 10/23/2013 02:37 PM, Paul Sokolovsky wrote:
Quite. We have this functionality already and it's as simple as: apt-get install qemu-system-x86
Not sure if debian has packaged the statically-linked version whch lets you run random foreign binaries in chroots, but that's a small matter.
Do you mean qemu-user-x86? That lacks futex() implementation so wouldn't run anything more or less interesting... But yep, fixing that would be a good task for someone young and ambitious to learn to hack ;-).
$ > ./fix-exclusive-for-inclusive good task for _anyone_ ambitious to learn to hack.
I'm not ambitious hardly at all, and I don't really like Debian that much.
Plus, I can't imagine that doing the emulation entirely in software is beneficial performance-wise vs. what I'm suggesting. It's *easier* but I don't think it's *better*. (I'm open minded tho. You're the experts, I'm not.)
On 10/23/2013 03:47 PM, Christopher Havel wrote:
On 10/23/2013 2:54 PM, Scott Sullivan wrote:
On 10/23/2013 02:37 PM, Paul Sokolovsky wrote:
Quite. We have this functionality already and it's as simple as: apt-get install qemu-system-x86
Not sure if debian has packaged the statically-linked version whch lets you run random foreign binaries in chroots, but that's a small matter.
Do you mean qemu-user-x86? That lacks futex() implementation so wouldn't run anything more or less interesting... But yep, fixing that would be a good task for someone young and ambitious to learn to hack ;-).
$ > ./fix-exclusive-for-inclusive good task for _anyone_ ambitious to learn to hack.
I'm not ambitious hardly at all, and I don't really like Debian that much.
You do yourself a disservice in that description. No one is ambitious in all things, but in the schematics you provided, your ambition showed through there.
Plus, I can't imagine that doing the emulation entirely in software is beneficial performance-wise vs. what I'm suggesting. It's *easier* but I don't think it's *better*. (I'm open minded tho. You're the experts, I'm not.)
Try, but that's the only way to do it unless the hardware was designed for it. So your suggestion about using the second core for the conversion is still a software solution, an ergo there is an existing code base for it with qemu (regardless of which distro you run it on).
On 10/23/2013 4:53 PM, Scott Sullivan wrote:
On 10/23/2013 03:47 PM, Christopher Havel wrote:
On 10/23/2013 2:54 PM, Scott Sullivan wrote:
On 10/23/2013 02:37 PM, Paul Sokolovsky wrote:
Quite. We have this functionality already and it's as simple as: apt-get install qemu-system-x86
Not sure if debian has packaged the statically-linked version whch lets you run random foreign binaries in chroots, but that's a small matter.
Do you mean qemu-user-x86? That lacks futex() implementation so wouldn't run anything more or less interesting... But yep, fixing that would be a good task for someone young and ambitious to learn to hack ;-).
$ > ./fix-exclusive-for-inclusive good task for _anyone_ ambitious to learn to hack.
I'm not ambitious hardly at all, and I don't really like Debian that much.
You do yourself a disservice in that description. No one is ambitious in all things, but in the schematics you provided, your ambition showed through there.
Plus, I can't imagine that doing the emulation entirely in software is beneficial performance-wise vs. what I'm suggesting. It's *easier* but I don't think it's *better*. (I'm open minded tho. You're the experts, I'm not.)
Try, but that's the only way to do it unless the hardware was designed for it. So your suggestion about using the second core for the conversion is still a software solution, an ergo there is an existing code base for it with qemu (regardless of which distro you run it on).
There's a difference between knowing you can help and contributing, and ambition, I think -- I neither need nor want to be a celebrity of any kind. I like to help people, but it's for them not me.
As for the programming bit... I type *./compile** **make* and gcc goes off and tries to build me a magic chocolate factory and fails dramatically, usually pretty early on. IIRC I've had possibly one example where I got it to work without any fatal errors... if that's correct it was with a weird and very primitive nothingburger WM. It was only available as source code, was very inflexible (changing any parameter anywhere required changes to source and therefore a recompile), and --most importantly for me-- didn't support a "start menu" natively. I was initially attracted because it had an interesting way of doing one very minor thing -- the close/minimize buttons were on the side of the window rather than in the titlebar. Of course I can't remember the name of the WM now... probably just as well.
I have some minimal experience with QBASIC, but that's as successful as I've been. I made a minimal text adventure game that worked without having a proper parser (trust me, you don't want to know how I did that) and I do want to say that I got all the bugs out of it eventually, so that it's actually playable through...
I know my strengths and programming isn't one of them. At least I know it and admit it...
arm-netbook@lists.phcomp.co.uk
-
Christopher Havel -
luke.leighton -
Paul Sokolovsky -
Scott Sullivan -
Wookey