Porting Various Operating Systems To Pandora?

[ldesnogu]

If that's the case then either A9 was being developed concurrently with A8 or it took much, much less time to develop. It's not as if out of order was invented 5 years ago, and for that matter Silverthorne is being released hardly any later than A8 is being adopted, so the same argument could apply to both (except there was no superscalar ARM before this, and x86 has been superscalar for over a decade)

Re-read my original statement: I was talking about embedded market at that time. As an example, you know OoO has been used for 40 years? It took more than 20 years for Intel to adopt it on the desktop.

QUOTE
I'm not really getting how any of this means that it means nothing, it just means that it has to be compiled a certain way, although I suppose lack of certain optimizations will forces the compilation used down to something unpleasant. I still think the numbers have shown something in terms of relative performance, even if the test is flawed.

If you don't get it, I can't help you, sorry. Did you ever look at the source code? Did you ever see what some vendor compilers do with it? Did you ever see designers use it?
Now if you can show me how it shows any relative performance... (BTW didn't we already have this discussion months ago? ) We can do an exercise: pick dhrystone numbers, compare them to spec2k on similar machines, and see if they relate.

QUOTE
I don't know how ARM defines architecture, but this isn't just about ARM. I've never heard of anyone refer to x86, the ISA, as an architecture. I'm going to assume ISAs are what were being referred to anyway. I do believe that "architecture" has connotations of physical design (like a building being made) rather than a more general language and model. I take it you call ARM9, ARM11, etc "implementations" then? Or does ARM have a more suitable term?

Yes ARM calls ARM9 and ARM11 implementations of ARMv4 (or ARMv5TE for r2) and ARMv6 (plus extensions) architectures.

BTW what does IA32 stand for?
And look at the titles of Intel manuals: http://www.intel.com/products/processor/manuals/index.htm

QUOTE
When I say elegant I mean for the PROGRAMMER, not someone designing a CPU that uses it. For someone citing years of experience programming it and not designing CPUs that utilize it I can only think that's what he meant, and for the many more people that program it than design CPUs around it I can only guess that's what's going to be the relevant factor (even if far less people use ASM now).

Of course MIPS is simple to implement, that's a major part of its premise. It's also a major compromise in what you can do with it. The simple encoding and lack of addressing modes real require multiple instructions where ARM would not (great example is picking a random element off of an array). Lack of flags I'm okay with, but is more something you can get away with with more registers, which ARM deliberately avoided for more flexibility. For as simple as it is, simple by itself does not mean elegant. It only succeeds in being elegant if it can accomplish the same things with its simpler set of tools - in some ways it can, but in other ways it really can't.

And don't even bring Thumb into this while ignoring MIPS16, which is a concurrent option for MIPS designs.

I once knew a professor (he worked with HP on the Dynamo project) who taught a CPU design class that implemented ARM. He told me that despite how it would appear to one emulating it in software, ARM was in fact not at all complex to decode. If undergraduate students can do it then I suspect that he can't be so far off the bill on that one, even if MIPS is easier (at an obvious price). At any rate, wouldn't you think that by now other architectural (and no, I'm not using the word like you say ARM does) complications have long since eclipsed the difficulty in decoding fixed length instructions?


I was thinking about Thumb2 which is not fixed-length. This is a real pain to decode. So much, that one day it will take 2 cycles. And that testing it is hugely time-consuming. This also causes problems to branch prediction.

For me something elegant is something clean and simple.
According to your views later 68040 and VAX would then be the top for assembler programmers

 

[Exophase]

Re-read my original statement: I was talking about embedded market at that time. As an example, you know OoO has been used for 40 years? It took more than 20 years for Intel to adopt it on the desktop.

I understand that you were talking about the embedded market at the time, but just because ARM had not yet done it doesn't mean that they needed to do in-order superscalar first. As I said, I can only imagine that they started development of A9 not especially long after A8 (compared to time between starting ARM11 and A8, although this is somewhat speculation based on announce dates), which suggests to me that A8 is a stepping stone to leverage the complexity of the transition, with A9 being the original intended goal. Obviously you know more about this than I would, but I'm sure you won't say if I'm at all right or not so it's moot

If you don't get it, I can't help you, sorry. Did you ever look at the source code? Did you ever see what some vendor compilers do with it? Did you ever see designers use it?
Now if you can show me how it shows any relative performance... (BTW didn't we already have this discussion months ago? ) We can do an exercise: pick dhrystone numbers, compare them to spec2k on similar machines, and see if they relate.

No, I don't remember having this discussion with you, sorry. I'm not interested in what tricks are done from partial parties, although I have suspected before that some numbers are skewed because of this. Results I have seen have seemed reasonable in showing relative improvements between processor iterations. I don't really have much problem dropping this though (I've never actually been interested in citing DMIPS).

Yes ARM calls ARM9 and ARM11 implementations of ARMv4 (or ARMv5TE for r2) and ARMv6 (plus extensions) architectures.

Okay.

BTW what does IA32 stand for?
And look at the titles of Intel manuals:

I already said I know what ISA stands for, you can't get me on this (basically I think if qualified with "instruction" beforehand that makes it completely ambiguous but whatever. I'll concede that "architecture" can refer to ISA, and that this was purely bad semantics on my part)

I was thinking about Thumb2 which is not fixed-length. This is a real pain to decode. So much, that one day it will take 2 cycles. And that testing it is hugely time-consuming. This also causes problems to branch prediction.

x86 is much worse than just having two portions, and has not ended up taking more cycles to decode a reasonably sized instruction - of course this is mitigated across pipelining. If you mean will take two pipeline stages then erm.. okay? Doesn't seem like the end of the world.

For me something elegant is something clean and simple.

Elegance is a notion of grace and beauty, not merely simplicity.

C is a good example of a simple language, because it's small - but it also doesn't really have a lot of expressive power. Granted, some aspects may be: I consider the unified nature of strings, arrays, and pointers to be one such example because it gives you a small amount of language that does a lot of useful things.

Scheme is what I would consider a more thoroughly elegant language - it's small but its basic constructs are all very powerful.

According to your views later 68040 and VAX would then be the top for assembler programmers

Not really. Adding a lot of (especially relatively specialized) facilities certainly doesn't make something more elegant because it's no longer small but simple. It's not just about being able to do many things: if you want to do lots of things then abstract it out to a higher level and you get the same thing (and indeed, with heavily microcoded processors this was exactly what the CPU was giving you). ARM lets you do a lot in one instruction, a lot of things that have general purpose uses that 68k really doesn't give you and VAX never did in a way that feasibly allowed for efficient implementation.

 

[Svartalf]

x86 and ARM are not architectures, they are instruction sets. If indeed you do mean to talk and instruction sets then please qualify why you think there are other RISC ISAs that are far superior to ARM. And no offense, but please do it with actual reasons and not just by saying how many years you've programmed in such and such for so and so. I'm getting kind of tired of that general line of argument from people.

Heh... Intrinsically, there's things going for ARM, there's things against it.

ARM's good for media engine stuff. It's got enough bang for buck that it gets used quite a bit on the low end.

Take a look at what gets used where- and then start asking why.

ARM's not TYPICALLY used in a router or switch. MIPS is.
ARM's not TYPICALLY found in engine control computers, it's usually PowerPC believe it or not.

Why is that? Not architecture bias. Not manufacturer bias. It's because each does it's job better in the spaces you're finding them in.

While the ARM allows for denser instructions, those come at a price- if you're not doing the barrel shift ops and doing straight up math manipulations, etc. the MIPS will win out over the ARM at the same clock speed because I will have more register space so I can optimize the code better. It's why the ARM is better than the x86 in many cases at the same clock- it's got more registers than anything else. When you're doing the types of operations that are needed for a router or a switch, the ARM will have to be a much higher clock-speed machine on average to keep up- your "elegance" cost you on your BOM if you're doing a router.

The PowerPC doesn't have pretty instruction sets compared to the ARM, but it'll do the needed calculations for engine tuning in real-time quicker than the other two at a lower power level for the class of CPU you're using. ARM can't go there because it usually doesn't have floating point and a few other gotchas like it.

ARM gets used in PDA's and SmartPhones because it's got the best bang for buck on code size and overall execution speed for the device profile we're discussing, including overall power consumption at speed. It USED to be SH4's used in that space. If someone comes up with an x86 that has the same power/speed profile and with memory getting as cheap as it's getting both on power consumption and overall cost on BOM, you're going to see people try it because of the large base of installed code and the overall familiarity with the ISA. If ARM can get closer to the peak speeds that the "big boys" (That would be MIPS, Power, Sparc and x86) and had similar register profiles to the MIPS or Power machines, you'd have me singing it's praises because it would be closer to an ideal ISA.

For some tasks, the ARM is the best thing since sliced bread. I'll even tell you this.

Is it the "most elegant"? Hell, no. There is no such beast. Never was. Probably never will be because each one takes design shortcuts to accomplish what the designer sees as his/her ultimate goal with the ISA.

QUOTE

For the record, pretty much everyone I've ever talked to who has programmed in multiple ISAs thinks that ARM is the most elegant they have used. I'm familiar with all of the instruction sets you've listed and I can't think of any of them that offers conditional execution, folded barrel shifting, optional flag setting, PC as a register, and the flexible addressing modes ARM does (I don't mean none of them offer any of this, but none to the degree ARM does). There are benefits, but they're mainly limited to more registers or lack of flags. MIPS and SPARC in particular are pretty bottom of the barrel when it comes to power per opcode.



Elegance by itself doesn't cut it. Performance per cycle, per watt, for a given application does. If elegance cut it, we'd be using stack engine CPUs right now because they're more elegant and easier to deal with than most designs, including the ARM (And if you're wondering, there's nice swedges of the on-board embedded systems on the Space Shuttle, comm satellites, etc. that USE Forth as at least the Assembly language of the CPU...). It's got to bring more than "elegance" to the table. I strongly suspect that we're going to agree to disagree right at the moment.

QUOTE

EDIT: Since I figure someone's gonna say it, yes I know ISA stands for "instruction set architecture." But usually when people say architecture they mean a particular CPU design.



I'm old school. I've probably been at this kind of stuff for longer than most of the people on this board.

When I say "architecture", that is PRECISELY what I'm referring to.

And your answer indicates what I was wondering. You're looking for elegance. Fair enough. I'm more of a practical kind of fellow- I want the damn thing to work, I don't give a flip about how "ugly" the code or the machine might be. This is why I suspect we're going to agree to disagree a bit on this subject.

 

[Svartalf]

I don't know yet if I will get a Pandora or not. What I am sure is that if I would get one, it would be to play at assembly level, both on the ARM core and the c64x. I have various projects in mind. Too bad craigix found no time to answer my e-mail

Then you do have a fairly legit reason. I'm interested in one much for that reason as the UMPC aspects, but so many just "like" things because they're not that arse-ugly x86 ISA (which I wish fervently would die for something sane like MIPS or POWER instead of this morphodite thing they've come up with over the years in x86... )- I always have to wonder what their reasons are. Not so many are honest about those sorts of things.

QUOTE

I disagree (surprise ): most of the time rendering performance is hidden by network speed, or lack of it. It has almost nothing to do with end user experience.



If you're comparing end-user experience, then YES, that would be a good benchmark; keeping in mind that anything other than a synthetic situation will be inconclusive because the Internet throws so many variables into the mix you can't use it as a metric. But if you're doing side by sides of the overall performance of the machine architectures, then network performance is far too variable a thing to use for that metric.

QUOTE

I have been playing with standard benchmarks (from dhrystone up to spec2k) and I can tell you it's easy to double or halve the speed even for spec2k depending on the OS conditions (and no I am not talking about a loaded OS, I am just talking about funny effects of TLB).



Heh... It's why I don't trust anything I've not turned the knobs around a bit on for myself. Even then, I question it. Benchmarking's a funny beast, no?

QUOTE

It's like the PC world: do you really look at synthetic benchmarks when you build your PC? Or do you look at the speed of the type of games or applications you will use?



A little of both, actually. In the end, it may be...difficult...to obtain metrics on the applications base you need to check against. In the end, I end up buying something and then using it as a referant for future purchases. There's been more than once where I dumpstered something because it looked good on paper and on a couple of my applications only to find out that it only shined in those places.

QUOTE

So when I am presented with the Intel slide about browser performance, I call it pure bullshit (also note others on this thread have already told how bad this slide is due to lack of real information about the conditions).



Calling it bullshit is as bad as calling it gospel without info, in my not so humble opinion.

Either extreme, without solid proof, is a faith (or lack thereof) based response. I don't like those...

QUOTE

So I have more experience than you



That would be the MODERN CPU ISA's...

1802
6502
6800
6809
8080
Z80
Z8000
680x0

and a few others...

QUOTE

I seriously hate x86(_64) ISA, any RISC is so much funnier to program



Funnier or "more fun"? I think you're not alone in that desire. I only questioned your comment because I was curious what drove the remark.

QUOTE

As far as RISC ISA's are concerned, MIPS is the cleanest one, though I don't know what it has become, I have not used it since 10 years.



MIPS is still pretty clean. POWER 5's not bad either.

 

[ldesnogu]

QUOTE

So I have more experience than you

That would be the MODERN CPU ISA's...

1802
6502
6800
6809
8080
Z80
Z8000
680x0

and a few others...
I have done half of them, plus Saturn. I even remember the Z80 opcodes, I had not enough RAM for an assembler

I still remember the first day I saw the assembly output of a RISC compiler. It was in 91 on an Ultrix DECstation. It also was my first real contact with UNIX. After that there could be no turning back.

You said you had more than 20 years of experience, I have more than 25. Now that will irritate others who say this doesn't prove anything and they're right. Except for one thing, old timers had to learn the price of everything the hard way, so they tend to optimize more; which does not mean young programmers can't do that, just there are less of them pushing things to the limit :rolleyes:

That was my "I feel old" post

 

[Svartalf]

That was my "I feel old" post

You missed the "Now get off my lawn, you young whippernsappers".

 

[randomhack]

QUOTE

So I have more experience than you

That would be the MODERN CPU ISA's...

1802
6502
6800
6809
8080
Z80
Z8000
680x0

and a few others...
I have done half of them, plus Saturn. I even remember the Z80 opcodes, I had not enough RAM for an assembler

I still remember the first day I saw the assembly output of a RISC compiler. It was in 91 on an Ultrix DECstation. It also was my first real contact with UNIX. After that there could be no turning back.

You said you had more than 20 years of experience, I have more than 25. Now that will irritate others who say this doesn't prove anything and they're right. Except for one thing, old timers had to learn the price of everything the hard way, so they tend to optimize more; which does not mean young programmers can't do that, just there are less of them pushing things to the limit :rolleyes:

That was my "I feel old" post


:blink:
Your experience > My age
Miles to go before I sleep.
On the assembler side I have experience in .. hmm .. PTX (the Nvidia CUDA pseudoassembly .. this is what i am doing professionally) and JVM bytecode (at home). Currently learning ARM for fun and hope to proceed to some DSP stuff (c55x or c64x). Somewhat different from most people.

 

[netbsd]

I'm getting concerned. Let's say I want to do a NetBSD port, or perhaps even something more exotic like L4. I have learned from this discussion not everything is open source or has open documentation available. For instance, 3D accel.

What else would be crippled or broken if I were to abandon Linux, starting from the boot loader and up?

 

[chad78]

Ok - I skimmed over a lot of this "My CPU is better than your CPU" stuff - and the GPL sucks stuff, too. (Although the storytelling of the epic battle between the hordes of GPL death squads and the Guardians of Perpetual Hope (GPH, get it?) was a good read, Chip!)

Getting back to the stated subject of this thread.

• Maemo (yes, it's Linux, but it's a specific Linux I want to see on Pandora.)
• Ubuntu (again, a specific type of Linux that has already proven it can live on a machine with less power than Pandora --- Maybe this should read "Desktop Linux" instead of Ubuntu specifically.)
• FreeDOS
• FreeBSD (since they use the BSD liscence instead of GPL - that might help avoid some attacks)
• ReactOS (kind of pushing it, the OS, not the hardware. I have yet to be impressed with this years of pre-1.0 release software)
• PSP Custom Firmware ... Imagine running PSP ISOs natively! The more powerful hardware should cut down on loading times a lot!
• Android - yeah, it's not a phone, but you know there will be a lot of software for the Android platform that is not phone related

 

[Chip]

• Maemo & Android - There is certinly some decent software there, but do you really need the whole OS? Maemo is (and Android likely will be) compiled for ARM, so a compatability layer would be much more desireable. Do you raelly want to have to reboot into a different OS every time you want to use a different app? In any case, I'm sure somebody will at least try both of them and I wouldn't be shocked if they succeed.
• Ubuntu & FreeDOS - You run into a problem with program compatability here. Even if you port the OS, none of the existing software is compiled to run on ARM processors. Not really worth the trouble.
• FreeBSD - There is an ARM version and presumably some software for it. Whether it's worth all the trouble just to avoid licensing issues which don't appear to exist any more is anybody's guess.
• ReactOS - Not yet ready for prime time. The ARM version is not even ready for late night public access. Besides, you still run into the same problem of having to re-compile everything like with Ubuntu and FreeDOS.
• PSP Custom Firmware - The PSP runs on different (MIPS) hardware. You'd have to actually emulate it (not going to happen) to run any PSP software natively.

[/quote]

 

[ldesnogu]

• Ubuntu & FreeDOS - You run into a problem with program compatability here. Even if you port the OS, none of the existing software is compiled to run on ARM processors. Not really worth the trouble.

Why did you put Ubuntu and FreeDOS in the same league? Ubuntu has recently been compiled entirely (at least 10,000 packages) for ARM, using a cluster of XScale racks
QUOTE

• FreeBSD - There is an ARM version and presumably some software for it. Whether it's worth all the trouble just to avoid licensing issues which don't appear to exist any more is anybody's guess.

GPLv3 is alas posing lots of issues in the industry (for instance, I can't use the latest gcc at work). Happily this should not affect the Linux kernel itself.

Back to general problem of porting an OS, as far as I know anything should be doable. Even integrating the binary OpenGL ES 2.0 driver could be achieved by a talented hacker with some inclination towards reverse-engineering

The only concern we might have is if the boot ROM inside the OMAP3530 uses TrustZone and prevents us from entering monitor mode. But even in that case, that may not be an issue.

 

[Chip]

Why did you put Ubuntu and FreeDOS in the same league? Ubuntu has recently been compiled entirely (at least 10,000 packages) for ARM, using a cluster of XScale racks

I had no idea. There was no mention of it on either the Ubuntu page or Wikipedia.

 

[ldesnogu]

I had no idea. There was no mention of it on either the Ubuntu page or Wikipedia.

Here is the link for the information: http://linuxdevices.com/news/NS2097004728.html

 

[Exophase]

Why did you put Ubuntu and FreeDOS in the same league? Ubuntu has recently been compiled entirely (at least 10,000 packages) for ARM, using a cluster of XScale racks

Compiled for ARM, by ARM, eh? Of course my first inclination was "that sounds a little inefficient" but after reading the article I can see why they did that...

 

[ldesnogu]

Compiled for ARM, by ARM, eh? Of course my first inclination was "that sounds a little inefficient" but after reading the article I can see why they did that...

Blasphemy! XScale was not designed by ARM, but by Digital and then Intel

 

[Svartalf]

Blasphemy! XScale was not designed by ARM, but by Digital and then Intel

...as a derivative work of the ARM ISA and design...they had to get a license to do that, according to my understanding of things...

 

[ldesnogu]

...as a derivative work of the ARM ISA and design...they had to get a license to do that, according to my understanding of things...

They used an architecture license ( http://www.arm.com/products/licensing/ ) but it was most probably not derived from an existing ARM design.

 

[Exophase]

Compiled for ARM, by ARM, eh? Of course my first inclination was "that sounds a little inefficient" but after reading the article I can see why they did that...

Blasphemy! XScale was not designed by ARM, but by Digital and then Intel

So you're saying XScale can not be considered an ARM platform? I meant by ARM CPUs, not by.. ARM themselves. ^^

 

[randomhack]

Compiled for ARM, by ARM, eh? Of course my first inclination was "that sounds a little inefficient" but after reading the article I can see why they did that...

Blasphemy! XScale was not designed by ARM, but by Digital and then Intel

So you're saying XScale can not be considered an ARM platform? I meant by ARM CPUs, not by.. ARM themselves. ^^


XScale is based on ARMv5TE ISA according to wikipedia except for floating point instructions.

 

[Exophase]

XScale is based on ARMv5TE ISA according to wikipedia except for floating point instructions.

I know that :/