x86_64 Status update
Hello everybody!
It was really a huge break in posting - I hope that you are still with me here :-)
The x86_64 kernel is moving forward, although my development has been slowed down recently. I have to complete my PhD thesis which is of the highest priority at the very moment. But I do my best and in my free time I continue writting the x86_64 kernel.
Recently, I have switcheed over to C++ language, in order to simplify my work (through templates) to use the object-oriented approach (so should it be on AmigaOS-like operating system) and to clearify the source code. It is not a complete C++ implementation - it does not include the STL and libstdc++ even. But it works pretty well.
One of the C++ ideas which I have borrowed from the C# language are events and generics. The EventHadler template is used to generate function objects which may call several different methods (or functions) at the same time. In order to clearify it, have a look at the following code:
[...]
EventHandler<char> ev;
ev += Function1;
ev += Function2;
ev("C++ is nice");
[...]
where the Function1 and Function2 take the char* as the only parameter. Both of them will be called with the "C++ is nice" string in the argument.
Stay tuned for more news :-)
It was really a huge break in posting - I hope that you are still with me here :-)
The x86_64 kernel is moving forward, although my development has been slowed down recently. I have to complete my PhD thesis which is of the highest priority at the very moment. But I do my best and in my free time I continue writting the x86_64 kernel.
Recently, I have switcheed over to C++ language, in order to simplify my work (through templates) to use the object-oriented approach (so should it be on AmigaOS-like operating system) and to clearify the source code. It is not a complete C++ implementation - it does not include the STL and libstdc++ even. But it works pretty well.
One of the C++ ideas which I have borrowed from the C# language are events and generics. The EventHadler template is used to generate function objects which may call several different methods (or functions) at the same time. In order to clearify it, have a look at the following code:
[...]
EventHandler<char> ev;
ev += Function1;
ev += Function2;
ev("C++ is nice");
[...]
where the Function1 and Function2 take the char* as the only parameter. Both of them will be called with the "C++ is nice" string in the argument.
Stay tuned for more news :-)
posted by Michal Schulz at 09:24
6 Comments:
Hello Michael
First of all I want you to know that I admirer ALL your work on AROS. Not just you but all of you on the AROS project.
I have a suggestion to your AROS project:
1.: Why don't you make an OpenGL driver that can run on ALL grapic cards so you don't have to make specific drivers for specific graphic cards?
2.: Why don't you make an OpenAL driver that can run on most modern soundcards, so you don't have to write specific sounddrivers for specific soundcards?
I wish your AROS project all good in the future.
Greetings from
Mikael Arling from Denmark.
(e-mail: arling@ofir.dk)
I use AmigaOS and Linux whenever possible.
> 1.: Why don't you make an OpenGL
> driver that can run on ALL grapic
> cards so you don't have to make
> specific drivers for specific
> graphic cards?
Because even the OpenGL needs drivers for specific cards. OpenGL provides the same interface from the point of view of a 3D application developer.
> 2.: Why don't you make an OpenAL
> driver that can run on most
> modern soundcards, so you don't
> have to write specific
> sounddrivers for specific
> soundcards?
For exactly the same reasons as above. Even with OpenAL there has to be a driver which knows how to talk to the AC97 codec and how to programm the sound chip (or part of the southbridge) in order to feed the AC97 with data.
Ok.
I have just heard that OpenGL and OpenAL could work on most modern Gfx- and soundcard without question.
Thanx for the answer, and thanx for updating me.
Mikael
As AROS is Open Source already, you could have saved yourself some trouble by using the exokernel from M.I.T., and building-in more advanced features for the 64-Bit version--greater speed, flexbility, and backward compatability.
> As AROS is Open Source already,
> you could have saved yourself
> some trouble by using the
> exokernel from M.I.T., and
> building-in more advanced
> features for the 64-Bit
> version--greater speed,
> flexbility, and backward
> compatability.
If you would carefully look at the internal structure of AROS, you would notice that our approach is not a monolythic kernel (it never was in case of AmigaOS). It is not even a microkernel approach, although it may be called so by some individuals.
Instead, the internal structure of AROS is very close to the exokernel approach. The AROS itself (the exec.library) do not control anything but memory. Nothing except the exception and interrupt handlers work in the most provileged mode (CPL0).
Whole AROS is just a bunch of libraries which aim to simplify developer's life (do not reinvent the wheel). AROS is not owning your hardware - you may talk to it directly.
Look at our graphics subsystem. If you like, you talk directly to hardware (noone does it, due to variety of HW vendors). You may also use our driver (which is an OOP-object, similiar to a library) which talks to the HW instead of you. The last but not least, you may talk to the graphics.library, which is just another layer of abstraction (graphics.library talks to the driver class which talks to the hardware). Nowhere are syscalls, nowhere is any part of kernel code involved.
Now, look at eg. the SFS - Smart FileSystem. If you have read my older posts, you would notice, that the performance of the SFS is very close to the raw performance of the harddrive. Surely there is no place for 4x speed boost (less than 10% boost could be more reliable).
PS. You do not get the numbers shown in MIT exokernel presentation seriously, do you?
Remember, MIT exokernel developers compared it's performance against complex operating systems (like *bsd, linux or windows). You cannot imply that this benchmarks results are still valid while comparing MIT exokernel with AROS.
Thanks for posting, definitely going to subscribe! See you on my reader. Please come visit my site virtual office space give me any valuable feedbacks.
Post a Comment
<< Home