Is there a way to set Solaris running on SPARC to run on little endian mode?
I've been reading that the v9 architecture chip is a bi-endian chip, though by default, the system runs in big endian. How to switch it to little endian?
Thank you!
No the Little endian mode is pretty much just for making bus accesses easier. Since many newer sun machines have PCI which is little endian it made loads of sense to add support for a little endian mode. However I doubt you would use it much if ever in user code.
Using the bi-endian feature is pretty much kernel/driver specific.
Related
Some background:
I am a Computer Engineering major attending school right now, and I just completed a project that created a microprocessor with a super simple instruction set that ran on an FPGA. I chose to implement a simple file storage scheme, a VGA text only display output, and a PS/2 keyboard input. I wrote two main programs, a firmware that was in ROM in the processor and a kernel that provided a bunch of library type functions, and was capable of loading and executing files from the filesystem. This project was challenging and overall a lot of fun.
My Question:
I want to do some super low level programming on a modern computer, but I can't seem to find any resources or documentation that help me get started. To be clear, I want to find the proper documentation that would help me to write a program in C, x86, or x86-64 assembly that I could compile, and format into some form of bootable data. I know this is a daunting task, and typically not something a hobbyist would take on, but I know that it's possible (Terry Davis's TempleOS).
Are there any websites or books that I can read that will contain the specifics needed to make something like this?
Look out, you might just catch the bug. OS Development, though having a very small demographic, is still quite a thriving hobby. Once you start, you may not ever give it up.
Since your subject line states 64-bit and you use the term modern hardware, be advised that modern hardware no longer has the older style BIOS, where the developer wrote the boot process which included the video out, file system in, and other standard routines. Modern hardware now uses an EFI firmware which does all of the booting for you, including the reading from the file system(s). For modern hardware, OS development really starts with the OS Loader, the part that loads the OS, and this is done in a high level language such as C/C++. Very little if any assembly at all, in fact that is its point/purpose.
Don't get too discouraged, currently a lot of computers still allow the old style boot. However, the old style boot starts in 16-bit mode, moves to 32-bit mode, then if desired, moves to long mode (64-bit). There also are emulators that you can use so you don't have to have a separate system, just to test your development. I prefer Bochs myself, but I am a little bias since I wrote some of the code for it, namely most of the (original) USB emulation.
If you wish to dip your toes into this hobby, there are numerous places to start. I personally wrote a few books on the subject. They show you how to start from when the time the POST gives up control to your boot code, up to the point of a minimal Round Robin style task/thread switching OS, with all the necessary hardware and software basics to do so. There is a forum to OS Development, along with its wiki.
Again, a project like this is not for the faint at heart, though it is an enjoyable hobby most have found to be a very good learning experience.
I have been programming in java for 3 years but I have no experience with other languages. I want to know what I need to study in order to be able to make an operating system. Am most likely going to make my operating system based on Linux kernel. What programming languages should I be familiar with and what aspects of the pc hardware should I study. if you know any online tutorials or good books please mention them.
The answer depends on how far you want to go and how much you want to write yourself vs using existing code.
The most straightforward way is to have a look at Arch Linux or Gentoo and build your own, custom Linux setup. Approximate time needed to create a minimal working system: ~2 hours
You could, otherwise, compile the Linux kernel, build some software packages and put it all together yourself and create your own Linux distro - i.e your own operating system in a sense. Linux From Scratch will be an invaluable resource if this is what you decide to do. Approximate time needed to create a minimal working system: ~2-5 days
Say that's too easy for you but you're not ready to delve into the nitty-gritty of kernel development. You can write your own applications that run on top of the Linux kernel. Typically, you'd need to know C/C++ but any language that supports running on Linux/compiling to a Linux executable will work. Heck, you could chuck a (or write your own) Java runtime on and write your whole 'operating system'/user-space in Java. Approximate time needed to create a minimal working system: ~6-12 months
What about if you want to get down to programming your own kernel from scratch? Heck, Linux is overrated and you want to write your own kernel and it's going to be the next best thing! You would want to learn a bit about the platform you're developing on. At the very least, you'll need to know the assembly instructions of some special operations for your platform that can't be done natively in C like switching CPU modes. You'll definitely need to read up on the OS dev wiki for this and you should have a fair decent computer science background.
At this point, you shouldn't need too much other than a good tutorial, C, a little assembly, reference manuals for the hardware you're hoping to support and 3+ years of computer science background to get you started. Your boot loader that's booting your kernel should handle most of the hardware initialisation. Bootloaders like GRUB (I'm assuming you're developing on a x86 system) does so much for you that it can probably just jump to your kernel main function straight away without you having to do too much. Again, if you wanted, you could port or write your own Java runtime in C and write the rest of your kernel in Java! Approximate time needed to create a minimal working system: ~3-5 years
But, let's just say you're screaming for more pain and you want to write an operating system really from scratch and you don't want no bootloader doing a lot of the legwork. What do you need? Firstly, you'll need a lot more reference manuals. And you'll need to read up on a lot more assembly. Especially for Intel processors, there's a lot of work involved bringing the system up from 16bit mode to 32/64bit protected mode with paging (which is what I assume you want). You'll also want to know about every tiny quirk and weirdness of your platform that will affect your OS (these are often not documented; hooray!). Plus, all of the above. In short, you will need to study everything. Approximate time needed to create a minimal working system: 5+ years
Of course, this post is just scraping the surface of what is needed to even bring up a basic operating system capable of say, opening a web browser. The approximates roughly assumes a minimal working system is something capable of running a graphical web browser and will vary depending on how much you want to write.
I don't mean to be condescending but this is the kind of reality you'll be facing if you decide to write your own operating system. Nevertheless, it is a valuable learning experience if you can break the initial barrier or even just trying to set up your own Linux system.
First, I would say that you install any Linux OS on your system and get accustomed with it.
Second, for OS development you have to know C language. As for the Assembly language, it depends from where you start the OS development. If you will be using available bootloaders, then I don't think that you will be requiring to learn assembly language.
This is a website on OS development: http://wiki.osdev.org/Main_Page
There you will find all the stuff you need to know for the OS development. And also how to develop OS step-by-step.
Now-a-days, a "Eudyptula Challenge" is going on. It is a series of programming exercise for the linux kernel. You can find more info here: http://eudyptula-challenge.org/
Does such a implementation of Forth exists that allows you to take full advantage of multicore processors?
I recently became aware of colorForth which is the latest invention from Mr Moore (not ANS compliant) and is used on his new multicore chips.
It features 144 small forth computers on a single chip (and no clock!) for high efficiency.
EDIT:
Actually, colorForth is the IDE used for the chips. The flavor of (color)Forth running on the chip is called arrayForth.
Apparently. I don't know much about it, see Multicore processors, FORTH programming, and the relationship between software and silicon (published 2008-09-24).
You want to take "full advantage" of multicore processors. The excuse for multicore programming is that you need performance (you can do multithreaded with just one CPU).
In that case, I don't think I'd use Forth, as it is fundamentally an interpreter (yes, a fairly fast one).
Worse, for modern processors, each Forth word-dispatch being an indirect call is likely a pipeline break, which really slams processor performance, and Forth word-execution operates on stack elements instead of registers. So by using Forth, you are giving up computational advantage compared to C or C++ or even Fortran. What this means is that you are almost gauranteed to have to use more than one CPU with Forth to match the performance of a more traditionally coded and compiled language. Why start with a disadvantage?
The guys that want to do MP with Python puzzle me for the same reason.
There are Forth implementations that run on the bare-metal that DO compile machine code, and if you do a bit of research before you start typing you will see that in-fact:
Forth was the personal system in use by Chuck Moore since 1958
Forth is a language, a compiler, and operating system, an interactive debugger (where you get this idea of it being "interpreted") a bare-metal-as-Chuck-intended Forth system gets even better when you consider that this entire WORLD needs only 2 registers, and ALU, and a Program Counter to run. Programming in Forth is completely different than the stuff your operating system is likely made out of and so I think one should really look at "bare-metal" or even native (yes there are native stack machine processors) Forths before judging what is what.
it was exactly these "bare-metal" Forth implementations what were used for decades and are still highly used today in embedded devices where your desktop OS should probably never go.
Multicore Forth programming is possible with iForth. There are 32/64 bit implementations that work on Win7, Linux, and OS X. iForth generates native code: http://home.iae.nl/users/mhx/i4faq.html
I wonder how virtualization software such as VirtualBox or VMWare Workstation works? How can they create a virtual environment that is taken as a separate computer by operating systems? I'm almost sure the answer to this question is very deep, but I'd be well satisfied with basic theory.
How does VMWare work:
http://www.extremetech.com/article2/0,2845,1624080,00.asp
How does virtualizaton work:
http://blog.tmcnet.com/voip-enterprise/tmcnet/how-does-virtualization-work-and-why-is-now-a-good-time-to-check-it-o.asp
Server Virtualization FAQ
http://www.itmanagement.com/faq/server-virtualization/
In the simplest sense, a virtualised environment is to a native environment, what an interpreted language, like PHP, Javascript or Basic, is to a compiled language like C, C++ or assembler.
When a compiled binary executes, the binary machine code, is passed straight to the CPU. However when an interpreted language runs, the language application reads in the code, then it decides what that meant and execute binary procedures to reflect that.
So virtualisation software like Qemu, while compiled to run on, say an x86 processor, will read the binary file, intended for say a Mac, and it will interpret the binary it receives, switch it from big, to little endian, and then know that op code X on mac corresponds to op code Y on x86, and that op code A on mac, doesn't have an equivalent on x86, so will need to call function B on x86 and so on.
The really clever bit, is the hardware interpretation, where someone has to write a driver, that will run on Qemu, on x86, but will present an interface to the Mac face of Qemu, to make Mac applications think they're talking to Mac hardware.
In the most basic sense, virtualization software puts a computer within another computer... kind of. (Here's a link that's very, very basic: http://blog.capterra.com/virtualization-software)
In a more complex sense, virtualization software (also called a hypervisor) abstracts the characteristics of a server. This allows several OSs to run on a single physical server.
I've been involved in embedded operating systems of one flavor or another, and have generally had to work with whatever the legacy system had. Now I have the chance to start from scratch on a new embedded project.
The primary constraints on the system are:
It needs a web-based interface.
Inputs are required to be processed in real-time (so a true RTOS is needed).
The memory available is 32MB of RAM and FLASH.
The operating systems that the team has used previously are VxWorks, ThreadX, uCos, pSOS, and Windows CE.
Does anyone have a comparison or trade study regarding operating system choice?
Are there any other operating systems that we should consider? (We've had eCos and RT-Linux suggested).
Edit - Thanks for all the responses to date. A pity I can't flag all as "accepted".
I think it would be wise to evaluate carefully what you mean by "RTOS". I have worked for years at a large company that builds high-performance embedded systems, and they refer to them as "real-time", although that's not what they really are. They are low-latency and have deterministic schedulers, and 9 times out of 10, that's what people are really after when they say RTOS.
True real-time requires hardware support and is likely not what you really mean. If all you want is low latency and deterministic scheduling (again, I think this is what people mean 90% of the time when they say "real-time"), then any Linux distribution would work just fine for you. You could probably even get by with Windows (I'm not sure how you control the Windows scheduler though...).
Again, just be careful what you mean by "Real-time".
It all depends on how much time was allocated for your team has to learn a "new" RTOS.
Are there any reasons you don't want to use something that people already have experience with?
I have plenty of experience with vxWorks and I like it, but disregard my opinion as I work for WindRiver.
uC/OS II has the advantage of being fully documented (as in the source code is actually explained) in Labrosse's Book. Don't know about Web Support though.
I know pSos is no longer available.
You can also take a look at this list of RTOSes
I worked with QNX many years ago, and have nothing but great things to say about it. Even back then, QNX 4 (which is positively chunky compared to the Neutrino microkernel) was perfectly suited for low memory situations (though 32MB is oodles compared to the 1-2MB that we had to play with), and while I didn't explicitly play with any web-based stuff, I know Apache was available.
I purchased some development hardware from netburner
It has been very easy to work with and very well documented. It is an RTOS running uCLinux. The company is great to work with.
It might be a wise decision to select an OS that your team is experienced with. However I would like to promote two good open source options:
eCos (has you mentioned)
RTEMS
Both have a lot of features and drivers for a wide variety of architectures. You haven't mentioned what architecture you will be using. They provide POSIX layers which is nice if you want to stay as portable as possible.
Also the license for both eCos and RTEMS is GPL but with an exception so that the executable that is produced by linking against the kernel is not covered by GPL.
The communities are very active and there are companies which provide commercial support and development.
We've been very happy with the Keil RTX system....light and fast and meets all of our tight real time constraints. It also has some nice debugging features built in to monitor stack overflow, etc.
I have been pretty happy with Windows CE, although it is 'heavier'.
Posting to agree with Ben Collins -- your really need to determine if you have a soft real-time requirement (primarily for human interaction) or hard real-time requirement (for interfacing with timing-sensitive devices).
Soft can also mean that you can tolerate some hiccups every once in a while.
What is the reliability requirements? My experience with more general-purpose operating systems like Linux in embedded is that they tend to experience random hiccups due to their smart average-case optimizations that try to avoid starvation and similar for individual tasks.
VxWorks is good:
good documentation;
friendly developing tool;
low latency;
deterministic scheduling.
However, I doubt that WindRiver would convert their major attention to Linux and WindRiver Linux would break into the market of WindRiver VxWorks.
Less market, less requirement of engineers.
Here is the latest study. The last one was done more than 8 years ago so this is most relevant. The tables can be used to add additional RTOS choices. You'll note that this comparison is focused on lighter machines but is equally applicable to heavier machines provided virtual memory is not required.
http://www.embedded.com/design/operating-systems/4425751/Comparing-microcontroller-real-time-operating-systems