Arm Development and Raspberry pi

[Techno Mage]

Since the Raspberry pi (http://www.raspberrypi.org/), is so cheap with the Highest price being Australia $38 + the cost of an SD card.
I wonder would this accelerate the development of the Arm version of React OS, since their can now be more people with devices to test.

[oldman]

On the same subject, this http://www.trustedreviews.com/opinions/raspberry-pi-hacks-the-most-wanted-list may be of interest to readers (there are two pages).
Someone is commenting on the possibility of different operating systems working on Raspberry pi.

[fLuXx]

I've just read a bit about raspberry pi and boy am I excited! I'd buy one right now if only it were on stock. Does anybody know when it will become available.

Now on a topic, I think if Ros was to be able to run on it, it might just be the wind in the back for the whole project. All it takes is for ReactOS to boot into GUI no matter how buggy. I don't know what is the current state of the Arm branch, but I reckon it does not yet boot into GUI. It would be nice if someone could tip us on that.

[DOSGuy]

I think that a cheap, tiny computer running a Windows-like OS would make a pretty impressive demonstration. Beyond getting the ARM port working well in general, ROS would also need to support the specific hardware that Raspberry Pi uses. It would require a dedicated effort to support this device. I think it would be a great shot in the arm for both projects, but I wouldn't expect anyone to stop working on ROS on x86 in order to work on this.

[Bblaauw]

Whenever no native port of ReactOS to ARM, QEMU emulating x86 on this ARM board should allow ReactOS to barely run.
Getting a no-nonsense Linux that only starts QEMU, is another matter.

[FlyingIsFun1217]

Whenever no native port of ReactOS to ARM, QEMU emulating x86 on this ARM board should allow ReactOS to barely run.
Getting a no-nonsense Linux that only starts QEMU, is another matter.

And what host would be running Qemu?

FlyingIsFun1217

[vicmarcal]

Whenever no native port of ReactOS to ARM, QEMU emulating x86 on this ARM board should allow ReactOS to barely run.
Getting a no-nonsense Linux that only starts QEMU, is another matter.

And what host would be running Qemu?

FlyingIsFun1217

Pick one: Debian, Fedora or ArchLinux

[FlyingIsFun1217]

I guess I'm confused. What would really be the point?

FlyingIsFun1217

[BrentNewland]

I've found some new information since the last time this topic came up, I figure I should share it.

http://reactos.org/wiki/ARM_Port#See_Also (note I'm only referencing the last section, the rest of the page hasn't been updated yet)

Running ReactOS on ARM processors and the Raspberry Pi? Last I heard it could install and begin the boot process, but crashed. That's not bad. From the Wiki, armv4 and armv5 are probably incompatible with ReactOS. RaspberryPi uses an Arm 11 (which is an armv6 processor). This page lists /proc/cpuinfo from QEMu emulating ARMv6. Ubuntu supported ARMv5 and ARMv6 in earlier versions, but dropped them (if ARMv5 is incompatible with ReactOS, I can understand that; ARMv6 didn't have many processors based on it though, so it may have been dropped due to lack of use). This page talks about some changes he needed to make to run an ARMv7 program on an ARMv6 processor (though minor), and this page lumps the ARMv4 and ARMv5 MMU's together, and the ARMv6 and ARMv7 MMU's together. This Page lists details on the ARM11 (ctrl+f arm11) as well as ARMv6 (which it lumps in with ARMv7 as well)(ctrl+f armv6).

Running x86 programs on an ARM processor? Possible. From my studies, an experienced emulator programmer said he believed you could do it at 50% of native speed (see the openhandhelds link on the wiki page above). From what I understand, only native (assembly?) code is run via an emulator. For the majority of Windows programs, they use the Windows API, which would (of course) operate in the ARM port (it's a core part of ReactOS). Therefore, any Windows API calls could be done with the ARM compiled API. Most programs are also written in a compiled language (like C/C++), which run using runtime libraries. If the runtime libraries are ported to ARM, then all that code would run native ARM as well (as long as everything returns the same value on ARM and X86). I might have the details off (would the emulator redirect the win32 or runtime calls to ReactOS, or would ReactOS handle it by itself?) but essentially it is possible, with a performance impact, but it's an excellent starting point.


What is the point? This is a cheap and easy way to get ReactOS ported to ARM processors, which will become important in a few years (at least to ReactOS). It may also encourage people to port ReactOS to different arm platforms, such as their cell phone (where I think ReactOS could do great in, what other phone OS even has a taskbar or has a remote chance of running any windows apps?). Porting ReactOS to other platforms (in the past) has revealed many areas of improvement. Actively supporting a different architecture might give them some key insight into the operation of Windows.

[Z98]

Nothing that requires time and manpower to accomplish is "cheap" and "easy." The existence of the raspberry does not magically make the actual writing of code for ARM easier.

[EmuandCo]

Wtf are you talking? You can't simply port a runtime or pray that a executable does not use any assembler, because the compiler generates this assembler. You are not able to run any built app inside any strange architecture just by trying to call any strange ported API calls. whoever told you that should really read some stuff or ask and not claim absolutely wrong stuff...

[hto]

Perhaps he means that while x86 programs can run on ARM machine via an emulator, ReactOS itself (ported) will work on that hardware directly. QEMU already has ‘user mode emulation’ mode for Linux, BSD, Darwin. Somebody could add Windows / ReactOS

[BrentNewland]

Wtf are you talking? You can't simply port a runtime or pray that a executable does not use any assembler, because the compiler generates this assembler. You are not able to run any built app inside any strange architecture just by trying to call any strange ported API calls. whoever told you that should really read some stuff or ask and not claim absolutely wrong stuff...

First off, your hostile tone is NOT appreciated. As far as what I posted, from your reply I don't think you read any of the links, so I'll include some specific quotes on the subject. After you have looked into it a bit, you can provide some constructive feedback on a point by point basis.

From the Wine Wiki Page for ARM: Run the assembler parts of x86 in qemu and call function in Wine compiled for ARM, which might speed up some things (darwine tried that before, but they stopped because the byteswapping (big endian <-> little endian) was too much work, but ARM is mostly little endian, so we have a chance if everything works fine with packed structures.)

From the WINE Forums: The means to run dll code native arm and application inside x86 emulation could reduce a lot of the performance bloat issue. Yes this would be a huge undertaking. (Translation: Run code that calls other DLL's or Functions in Win32/Wine/Windows from native compiled DLL's, run x86 specific code under QEMU)

There is an effort to port Wine to the ARM platform. The problem is like that for the Mac PowerPC platform, you will need a CPU emulator
until Windows programs start to appear for the target platform. Running an emulator AND a bloated Windows program may prove to
slow for ARM processors as it did for the PowerPC platform.

Winelib is ported to ARM, just a few things missing but nothing critical. The problem on PowerPC was mostly the endianess, not the speed

Everyone forgets about qemu usermode emulation. One of the most advanced forms of paravirtualization. Of course current qemu usermode emulation is limited. It emulates at the syscall to kernel point. So every time application does a syscall the syscall is processed natively.
To make wine more possible on arm expanding this usermode emulation would be required. Very much like x32 interfacing with 64 bit code. So that library calls inside qemu could be processed outside in platform native code. So reducing the performance damage from emulation even introducing AOT(ahead of time processing) instead of JIT that qemu uses could assist.

Currently Qemu userspace operation is that it receives a system call request from a contain Linux application. Arch convert the request and send it straight on to the native Linux kernel then does the same to the kernel answers. Currently Qemu userspace operation is that it receives a system call request from a contain Linux application. Arch convert the request and send it straight on to the native Linux kernel then does the same to the kernel answers. Wine could use its own custom syscalls to call for operations processed outside in arm then have data returned to the virtualization. http://wiki.qemu.org/download/qemu-doc. ... e-emulator This is the documentation on the usermode emulation


From OpenHandhelds: Would it be possible to run windows application(games) using qemu for x86 to arm translation and wine for the windows api? (Note: Information below comes from "Exophase" who is described as "an emulation Guru")

Qemu's userspace x86 to ARM translation as it stands now should be much more efficient than the ARM recompiler currently present in DOSBox, which is very slow. Userspace emulation has its own simplifications that lead to faster code and Windows programs will be higher level/spend more time in driver code (especially for 3D things) that would run more quickly due to being emulated at a high level.

Qemu is probably capable of performing around a 15-20% native speed for typical applications, so a 50-100MHz Pentium 1 wouldn't be completely out of the question. I personally believe that userspace x86 emulation can do much better. I expect an average of over 50% native speed to attainable. M-HT's static recompiler is doing 40-50% on one test application and I believe that more aggressive optimization can have significant gains.

There are things that x86 programs do routinely that don't map directly to ARM. This includes memory operands (especially destination, ie read-modify-write instructions or RMW), call/ret which pushes/pops the stack, 8/16bit operations, 32bit immediate operands and address offsets, and some flag mismatches. These things mean that some x86 instructions will convert to two or more ARM instructions. With this conversion you would get results like what M-HT has with his static recompilation, which for his tests were 40-50% native. The thing is, ARM can do many things that x86 can't. It has three operand arithmetic and folded shifts which can eliminate a move or a shift instruction in x86 under relatively common circumstances. It has conditional execution which can eliminate small one armed (and sometimes two armed) if statements that got converted to branches. It has more registers which could possibly map to fixed locations on the stack eliminating some memory accesses. It has load/store multiple instructions which could fold sequences of load/store instructions on x86. Pre-post increment/decrement can also be folded into memory accesses. With aggressive optimization I would imagine that you can improve the performance of translated code by a noticeable amount.

Let me talk a little bit about what I called "user mode emulation" and why it allows for much better performance. Obviously OS HLE can improve things, like I mentioned, but there are two main things that make the burden of machine code emulation lighter than it is for full blown "system emulation." One is that you don't have to emulate physical device access, which means that the address space just consists of memory. Since the OS usually abstracts memory in some way you just need an OS on the other end that's compatible with what the program expects. In some cases it's even possible to arbitrarily relocate the program entirely. Memory emulation is one of the biggest drains in system emulation and being able to reduce it to native accesses improves things dramatically. The other benefit is that you don't have to emulate interrupts, meaning that you don't have to count cycles and abort when they run out. Cycle counting is both a performance drain and a pain to work with while allowing the code to be optimized.

The down side to all this is that you must emulate the OS at a high level. Fortunately, Wine is already doing exactly that.

(post)"It is possible to run windows programs in Linux on ARM but it takes more than just wine. Way back, when the Sharp Zaurus was big news some people managed to combine wine and qemu. Qemu was providing the processer emulation while wine provided the windows libraries. If you search you may still be able to find a tutorial about how to make that work. I have no idea what to expect performance wise but it would be an interesting experiment."

Now the goal of using LLVM would not be raw power, but more the ability to recompile to run the code natively. That's what QEMU does.

All this is widely discussed in several different areas by experts in the field. Of course, doing it with ReactOS would be different than doing it with WINE, but I imagine it would be faster.

And of course Windows 8 on ARM will also have the Win32 API.

This is a cheap and easy way to get ReactOS ported to ARM processors

Nothing that requires time and manpower to accomplish is "cheap" and "easy." The existence of the raspberry does not magically make the actual writing of code for ARM easier.

Having an inexpensive and basic hardware platform for testing a ReactOS port on seems like it would be cheaper and easier than waiting to buy an expensive Windows 8 tablet or trying to code on another ARM device (like a cell phone, which would require creating a bunch of drivers from scratch and a lot more work).

So, low price barrier to development = cheap, and minimalistic (and identical) hardware = easy (everything is relative). A cheap device purchased by tens/hundreds of thousands of coders/programmers? Lots of good contributors would certainly make writing an ARM port easier.



Windows 8 microsoft ARM build running on an ARM phone (just nice to look at, not really related)

[EmuandCo]

See? These information together with your former post and we would not have this lil discussion. Sure it works with an CPU emulator like the qemu way. I never said this is wrong, but your post sounds like you can just port the stuff around and it will run out of the box, which is plain wrong.
BTW, nice pic of Win8 on the Asus phone ^^ This was a new one to me.
We dont talk about the hardware needed for a port. Manpower ist expensive too, thats whats the problem here.

[Z98]

To rephrase EmuandCo's last statement, since the "cost" of manpower is so much higher than the "cost" of hardware, a decrease in the "cost" of hardware does not make a significant difference in the total "cost" of porting ROS to ARM.