Because nowadays, we are using compilers and interpreters to develop software and operating systems. Example MS Visual Studio, Turbo C++.
Well young fellow, we had to code them up in machine language is what. Not assembler, mind you. Machine language. Raw numbers. And without any a' them fancy macros, neither, no sir. And we had to carry our work to the machine room and then take the results back to our offices. Uphill. Both ways.
Related
Which programming languages provide the best support for self-modifying code?
In particular, since the program will need to make extensive use of self-modifying code, I am looking forward at the ability to remove from memory some parts of code, after they are no longer needed, thus freeing that memory. Also, it would be a plus if there was the ability to identify and index the routines (procedures, functions, etc) with some sort of serial number, so that they could be easily managed in the memory (deleted, cloned etc) at runtime.
Operating systems need to have some more-or-less "self-modifying code" in order to load programs and dynamic link libraries from storage into RAM and later free up that RAM for other things, do relocation fix-ups, etc.
My understanding is that currently the C programming language is by far the most popular language for writing an operating systems.
The OSDev.org wiki has many tips of writing a new custom operating system, including a brief discussion of languages suitable for writing an operating system -- C, Assembly language, Lisp, Forth, C++, C#, PL/1, etc.
Just-in-time (JIT) compilers also need to have some more-or-less "self-modifying code" to compile source text into native instructions and run them, then later free up that memory for the next hot-spot.
Perhaps you could find some OS project or JIT project and use their code with relatively little modification.
A few people, when they say they want "self-modifying code", really want a language that supports homoiconicity such Scheme or some other dialect of Lisp, Prolog, TCL, Curl, etc.
I'm a beginner programmer in my first year of Computer Science.
I'm curious about the 32 bit and 64 bit systems, and how it affects developing software.
When I download software I need to choose between the two, while other software only has a 32 bit version.
Are there different ways of programming for a 64 bit system?
Is it compiled in the same way?
What are the main benefits of a separate 64 bit app?
Cheers
Are there different ways of programming for a 64 bit system?
Yes and no. No, in the sense that most of the time you should be able to write platform-independent code, even if you are coding in a language like C. Yes, in the sense that having knowledge of the underlying architecture (not just the word size!) helps to speed up critical parts of your program. For instance, you may be able to use special instructions available.
Is it compiled in the same way?
Again, yes and no. Compilers for systems languages work in similar ways for all architectures, but of course, the details differ a bit. For instance, the compiler will use knowledge about your architecture to generate as efficient code as possible for it, but also has to take care of differences between architectures and other details, like calling conventions.
What are the main benefits of a separate 64 bit app?
I assume you are asking about the usual desktop CPUs, i.e. x86 architecture, but note that there are other architectures with word sizes ranging from 8-bit to 128-bit. Typically, people would compile a program targeting a single architecture (i.e. for a given machine), and that's about it.
However, x86 is a bit special, in that the CPU can operate in different modes, each with a different word size: 16-bit, 32-bit and 64-bit (among other differences). Effectively, they implement several ISAs (Instruction Set Architectures) in a single CPU.
This was done to preserve backwards compatibility, and it is key to their commercial success. Consider that, when people bought the first 64-bit capable CPUs, it was most likely that they were still using 32-bit operating systems and software, so they really needed the compatibility. The other options are emulating it (poor performance) or making sure all the popular customer software has been ported (hard to achieve in ecosystems like Windows with many independent, proprietary vendors).
There are several benefits of 64-bit x86 over 32-bit x86: more addressable memory, more integer registers, twice the XMM registers, a better calling convention, guaranteed SSE2... The only downside is using 64-bit pointers, which implies more memory and cache usage. In practice, many programs can expect to be slightly faster in x64 (e.g. 10%), but pointer-heavy programs may even see a decrease in performance.
Generally speaking the main benefit of 64 bit application is that it has access to more memory. Having 32 bit pointer you can access only 4GB of memory.
Most modern compilers have option to compile either 32 bit or 64 bit code.
32/64 coding is the same unless you are dealing with huge in-memory objects, where you would need to use 64 bit specifically.
An interesting fact/example is that Unix time is stored as a single number. It is calculated as a number of seconds passed from January 1st 1970. This number will soon reach 32-bit size, so eventually we will have to upgrade all of our systems to 64-bit so they can hold such a large number.
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.