I want to study and compare executable file structure of elf, SPARC and PA-RISC.
To perform the studies I want to install OpenSolaris on an Intel machine (Core2Duo).
But I got a basic doubt will it work at all ?
I know SPARC has its own assembly - grew in suspicion if it will work or is valid thought at all.
I was aiming to write some programs disassemble them and with some help of tools study the file structures.
I don't have any clue how to perform all this for HP-UX (PA-RISC); dont know any free OS for PA-RISC.
You won't be able to run Sparc or PA-RISC executables on an intel processor. However, if all you want to do is to analyse the structure of these executables, all you need is suitable development tools.
I haven't checked, but I suspect OpenSolaris comes with development tools capable of analysing Solaris/sparc executables out of the box. But even other toolchains can do that. For example, GNU binutils (specifically the BFD library they use) support many architectures, including Sparc and PA-RISC. (If you use GNU binutils, make sure you get a full version, perhaps labeled as “for cross-compilation”, e.g. binutils-multiarch on Debian or Ubuntu)
SPARC:
I have never installed OpenSolaris on anything. You might consider trying NetBSD: it runs SPARC machines at least as well as Solaris did, and it uses ELF format executables. The source code is freely available for study, too.
You will need to understand the ELF file format. I don't recall any particular document standing out back in the days when I wanted to understand ELF, and it looks like Google can offer a large number of web sites that will explain ELF. My advice on ELF is to write a program to read the ELF headers, and then dump them out in a readable text format, even though many such programs already exist.
You will also need a SPARC disassembler that understands ELF. I wrote one a long time ago, it will probably work reasonably well today. http://www.stratigery.com/elf_dis.tar.Z
You can download PDFs about SPARC here: http://www.sparc.com/specificationsDocuments.html I recommend the SPARC V8 and V9 architecture manuals.
PA-RISC:
This is a very odd architecture, with very little in the way of documentation. I believe that PA-RISC was Apollo Computer's (R.I.P) RISC architecture, then HP bought Apollo in 1990 or 1991. The stack grows down and the heap grows up, where just about everything else has it the other way around. It also has a segment register, but one that works differently than x86 segmentation.
HP is really the only place to find anything about PA-RISC.
There are ports for PA-RISC architectures of Linux, NetBSD and OpenBSD.
You cannot run code compiled for Sparc or PA-RISC on an x86 system, unless you use a full-fledge emulator. Qemu can emulate a Sparc-based machine, with enough accuracy for running a Linux operating system on it (but it will not be fast: Qemu must interpret all Sparc opcodes one by one, and this has a heavy overhead, so a fast PC from 2011 may perhaps yield the performance of a Sparc workstation from 1996). There is an ongoing project for adding PA-RISC support to Qemu but it does not seem to have reach any non-trivial level of usability yet.
Related
Given the availability of a new workstation (Intell Xeon X5690, Windows 7 Professional, 64-bit) for numerical analysis of fluid dynamics models, I find it a shame not engage in parallel computing. So far, I have had no or little experience in this field.
What's the difference between MS-MPI and the latest release of MPICH suitable for Windows? I installed MPICH 1.4.1, but I cannot get a test program to work on Ifort. How am I supposed to compile the program? Do I have to change Ifort configurations somehow to add the libraries of MPICH? Isn't there any good manual available online that could meet my needs?
There's lots of questions in this one question, but it all boils down to one basic question: How do I install MPI on Windows?
MPICH has long since worked on Windows. The last version that supported it was 1.4.1p1 as you've found, but it doesn't have any support anymore from the MPICH developers so if you have trouble, you probably won't find much help. I haven't seen anyone on here step up to help with those questions so far.
MS-MPI is a good option if you want to use Windows. It's free to use and still has support directly from Microsoft. You'll have to read their documentation about how to set everything up correctly, but it's probably the right place to start if you want to use MPI on Windows.
Intel MPI also works on Windows, but it isn't free so you might not want to look at that right now.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm really curious right now. I'm a Python programmer, and this question just boggled me: You write an OS. How do you run it? It has to be run somehow, and that way is within another OS?
How can an application run without being in an OS? How do you tell the computer to run, say, C, and execute these commands to the screen, if it doesn't have an OS to run in?
Does it have to do with a UNIX kernel? If so, what is a unix kernel, or a kernel in general?
I'm sure OSes are more complicated than that, but how does it work? It would be really brilliant to know this!
Thanks.
You can indeed write a program without an OS. Indeed, on your PC there is already a program that runs without an OS before your OS boots up. There are two in fact. The first is your BIOS.
The IBM PC architecture is one of a family of architectures that employs BIOSes to start up the computer. Not all architectures have BIOSes. The iPhone for example boots directly into a bootloader. In fact, most "modern" architectures don't have BIOSes but boot directly into a bootloader. It's actually conceptually simpler this way.
The fact that PCs need BIOSes is merely a historical legacy. The original IBM BIOS was in fact a basic bootloader for loading DOS. Modern BIOSes are still bootloaders.. that load bootloaders.
Most PC BIOSes are proprietary. They allow manufacturers to initialize custom/proprietary hardware before passing control to bootloaders. This makes it possible to write bootloaders without having to worry about weather the OS image is on a flash drive, a USB thumbdrive, an SD card, a magnetic disk, on DVD etc. The boot loader simply sees a disk that have been initialized by the BIOS.
The next stage of boot up is the bootloader. The reason why the IBM PC architecture requires a bootloader is that the BIOS is usually designed to set up the CPU to run DOS. Modern OSes require the CPU to be configured slightly differently. Also, modern OS kernels (a kernel is the actual core executable code of the OS doing things like manage memory, cpu etc) tend to be large beasts, often larger than 4MB in size which is much larger than what most BIOSes are designed to load. So the BIOS loads a small bootloader which in turn loads the actual OS. Again, this is only necessary due to decisions made by IBM in the 1980s when they designed the original PC architecture. Modern archictectures like the iPhone or PS3 don't do this. They boot directly into the bootloader.
The bootloader is necessary to solve the chicken and egg problem: to load the OS you need to read from disk. To read from disk you need to use a device driver which is loaded by the OS. To break this circular dependency people write bootloaders which are basically very simple OSes that is designed to run only one program (the OS) and understand how to read from disks (or SD card, or the network etc.).
Which brings us to the part that answers your question. If you've written an OS, how do you load it? You load it by configuring your bootloader. Windows comes with a bootloader that's not too flexible. It understands how to load Windows but that's about it. You can install open source bootloaders like Grub or Burg which understand how to load other OSes as well.
The fundamental concepts involved in booting a machine is actually simple. It's the details that's scary. But if you're really interested in how OSes work learning it is very rewarding in the end. Also, if you're interested in this stuff I'd suggest looking around at other architectures apart from the IBM PC like Mac hardware which uses EFI instead of a traditional BIOS or Linksys routers which boot into Linux directly from a bootloader or embedded platforms like Arduinos that run a single program you compile directly on the CPU without an OS.
You need an OS to do things like virtualize memory and arbitrate access to the hardware. Because the OS has full access to things like memory and the hardware, it doesn't need an OS to run. The services that most programs get from an OS, the OS itself either has to provide itself or has to get from the hardware.
What runs any software is some kind of a CPU, a piece of electronic circuitry, hardware.
Whether the software is an OS or some other kind of program, the CPU doesn't care. It just runs it so long as it is possible (e.g. until said software causes an irrecoverable error forcing the CPU to enter some odd state or simply reset).
When powered on, the CPU starts executing whatever code it finds at a certain location in memory. That location can be either hardwired in the CPU or configured by external to the CPU circuitry or even programmed by software. Which one it is depends on the CPU and how the entire device is designed.
Not all programs need an OS to run on a CPU. An OS is a good example of such a program. If every OS needed another OS how would you stop this infinite recursion? :) But it's not the only one.
Many electronic devices, especially very simple ones like a digital clock, don't have any OS in them.
About the only time an OS runs atop of another OS, is when you have virtualization. But I'm not going to go there in this answer.
An OS is only needed either for its basic functions like scheduling, thread/process synchronization, memory allocation, etc or to do all or most of device I/O itself and hide the hardware peculiarities from programs running in the OS, IOW, to allow portable programs. You write print 123 in Python and it prints 123 everywhere, in any OS with which Python is compatible (=for which it is available), irrespective of the display, its resolution and many other differences that can be there on different computers and in different OSes. If general-purpose OSes had not provided some common functionality (and some more or less common API for it) such as console and file I/O and memory management, Python would not have been available for them and those OSes would not have been general-purpose in the first place.
An OS kernel is the core of an OS. It does most of the low-level and dirty work, dealing with:
interrupt handling
thread/process scheduling and synchronization
memory management
things alike
Sometimes that's enough of OS functionality and in such a case there isn't any difference between an OS and a kernel, they are the same thing here.
If, OTOH, more stuff is needed, e.g. much flexibility, support for different devices, some code to manage all that and a bunch of special drivers for file system, for network and TCP/IP stack, etc, then a simple (perhaps, only relatively simple) kernel alone isn't sufficient, there needs to be more stuff around it and that's where you start differentiating between an OS and a kernel and arrive at OS = kernel + extras. The text editor you're using, even if it came with your OS, is not quite one of those extras, it's a regular program, which needed not to be bundled with the OS, but for convenience it could be.
UNIX is one example of an OS. There are many more, most notably Linux and Windows.
You should get yourself some book on computer architecture and organization to learn how computers work in general. What it is inside there, how it's put together, what's happening under the hood, etc.
I would want to compile existing software into presentation that can later be run on different architectures (and OS).
For that I need a (byte)code that can be easily run/emulated on another arch/OS (LLVM IR? Some RISC assemby?)
Some random ideas:
Compiling into JVM bytecode and running with java. Too restricting? C-compilers available?
MS CIL. C-Compilers available?
LLVM? Can Intermediate representation be run later?
Compiling into RISC arch such as MMIX. What about system calls?
Then there is the system call mapping thing, but e.g. BSD have system call translation layers.
Are there any already working systems that compile C/C++ into something that can later be run with an interpreter on another architecture?
Edit
Could I compile existing unix software into not-so-lowlevel binary, which could be "emulated" more easily than running full x86 emulator? Something more like JVM than XEN HVM.
There are several C to JVM compilers listed on Wikipedia's JVM page. I've never tried any of them, but they sound like an interesting exercise to build.
Because of its close association with the Java language, the JVM performs the strict runtime checks mandated by the Java specification. That requires C to bytecode compilers to provide their own "lax machine abstraction", for instance producing compiled code that uses a Java array to represent main memory (so pointers can be compiled to integers), and linking the C library to a centralized Java class that emulates system calls. Most or all of the compilers listed below use a similar approach.
C compiled to LLVM bit code is not platform independent. Have a look at Google portable native client, they are trying to address that.
Adobe has alchemy which will let you compile C to flash.
There are C to Java or even JavaScript compilers. However, due to differences in memory management, they aren't very usable.
Web Assembly is trying to address that now by creating a standard bytecode format for the web, but unlike the JVM bytecode, Web Assembly is more low level, working at the abstraction level of C/C++, and not Java, so it's more like what's typically called an "assembly language", which is what C/C++ code is normally compiled to.
LLVM is not a good solution for this problem. As beautiful as LLVM IR is, it is by no means machine independent, nor was it intended to be. It is very easy, and indeed necessary in some languages, to generate target dependent LLVM IR: sizeof(void*), for example, will be 4 or 8 or whatever when compiled into IR.
LLVM also does nothing to provide OS independence.
One interesting possibility might be QEMU. You could compile a program for a particular architecture and then use QEMU user space emulation to run it on different architectures. Unfortunately, this might solve the target machine problem, but doesn't solve the OS problem: QEMU Linux user mode emulation only works on Linux systems.
JVM is probably your best bet for both target and OS independence if you want to distribute binaries.
As Ankur mentions, C++/CLI may be a solution. You can use Mono to run it on Linux, as long as it has no native bits. But unless you already have a code base you are trying to port at minimal cost, maybe using it would be counter productive. If it makes sense in your situation, you should go with Java or C#.
Most people who go with C++ do it for performance reasons, but unless you play with very low level stuff, you'll be done coding earlier in a higher level language. This in turn gives you the time to optimize so that by the time you would have been done in C++, you'll have an even faster version in whatever higher level language you choose to use.
The real problem is that C and C++ are not architecture independent languages. You can write things that are reasonably portable in them, but the compiler also hardcodes aspects of the machine via your code. Think about, for example, sizeof(long). Also, as Richard mentions, there's no OS independence. So unless the libraries you use happen to have the same conventions and exist on multiple platforms then it you wouldn't be able to run the application.
Your best bet would be to write your code in a more portable language, or provide binaries for the platforms you care about.
X86 and AMD64 are the most important architectures for many computing environments (desktop, servers, and supercomputers). Obviously a JIT compiler should support both of them to gain acceptance.
Until recently, the SPARC architecture was the logical next step for a compiler, specially on high-end servers markets. But now that Sun is dead, things are not clear.
Oracle doesn't seem to be really interested in it, and some big projects are dropping support for that architecture (Ubuntu for example). But on the other hand, the OpenSPARC initiative intended to open source recent processors is quite promising, meaning that a lot of manufacturers could implement and use SPARC for free in the near future.
So, is SPARC still a good choice as the next target architecture for a JIT compiler? Or is it better to choose another one (POWER, ARM, MIPS, ...)?
I don't know any more than you about SPARC's future. I hope it has one; it's been tragic how many good architectures have died out while x86 has kept going.
But i would suggest you look at ARM as a target. It isn't present in big server hardware, but it's huge in the mobile market, and powers all sorts of interesting little boxes, like my NAS, my ADSL router, and so on.
Your next target architecture should definitely be ARM - power consumption in large datacenters is a huge issue and the next big thing will be trying to reduce that by using low-power CPUs; see Facebook's first attempt on this.
This question is for experienced Unix/Linux developers.
If you have found that you like Mac OS X better than *nix as a development platform, why is that?
I know that hardware configuration is more convenient and graphics are generally more polished, but I'm not referring to those things. I'm asking specifically about functionality related to software development.
Also, do the benefits still apply if you are mainly targeting Windows or Unix/Linux?
For most purposes, OS X is Unix. Aside from Xcode (which I personally don't care for), there isn't really anything there to make it better or worse than any other Unix-like system for development.
Most of the typical tools, libraries, languages, and interfaces are there, you'll even be using GCC for C/C++ work. As long as you're not developing against Apple/OS X-specific interfaces like Cocoa, you are developing on Unix.
I use OS X because it just works, thus not interfering with my development, not because it has magical fairy dust that makes it better than any other Unix for development.
I love Apple as a dev platform because I get all the power of the *nix commandline as well as Apple's developers tools (XCode).
The additional software/hardware polish, and quality of third party software make it all that much more enjoyable.
Mac OS X is not better than a Unix environment, it is a Unix environment: http://www.opengroup.org/openbrand/certificates/1190p.pdf
I'd go as far as saying it's probably the most used Unix, considering it's also in all iPod Touch and iPhones.
(As far as I'm aware, Linux isn't a certified Unix, but I may be wrong, perhaps a distribution/vendor went through that process.)
Sometimes, for professional reasons, you just have to have tools that are compatible with what your boss or customers use. This often includes proprietary tools like MS Office, whether you want it or not (OpenOffice can't always deal perfectly with Word documents). OSX provides this intermediate ground, where the developers can also be users or closer to their user base.