Writing an Operating System in Ada
in [ADA]
|
Prev: GNAT requires body of generic unit to be present at build?
Next: ASISEyes : show you the ASIS interpretation of an Ada source
From: Jean-Pierre Rosen on 14 Jan 2010 04:12 Leslie a écrit : > As a side note, does anyone here remember the Intel iAPX432 > processor, designed to execute Ada programs (almost) directly? > Yes I do. IIRC, the project failed because they completely missed the point. The processor was intended to be able to check the types of data at run-time, something that the compiler had already done. In a sense, it would have been a marvelous processor for any language but Ada - bringing Ada's type safety to other languages. There was a team who developped an Ada compiler for the iAPX432. When the project was disbanded, they were so frustrated that they decided to move their compiler to other targets and market it. The company was called Verdix... -- --------------------------------------------------------- J-P. Rosen (rosen(a)adalog.fr) Visit Adalog's web site at http://www.adalog.fr
From: Dmitry A. Kazakov on 14 Jan 2010 05:28 On Thu, 14 Jan 2010 01:40:57 -0800 (PST), Maciej Sobczak wrote: > On 13 Sty, 10:17, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: > >>> Interact with other systems? You know, you might want to sometimes >>> move your "persistent objects" to another machine. >> >> Marshaling? In terms of ADT it is assignment. Create a local object of the >> type. Assign the remote object to it. Done. > > What remote object? I just plugged in my USB stick or spun the DVD in > the drive. You said you wanted to move an object. > If you want to see a "remote object" in this operation, you will have > to somehow instruct the system that the "remote object" is the one > which is on USB. In which case there is no point in having it > (unnecessary step) as you might just as well instruct the system that > your *local* object should be constructed from what is on the drive, > by perhaps providing the file name. I.e. you don't want to move it... (:-)) > Which is exactly what we have today. > > The high-level OO abstraction still has to hit the bare metal at some > point, which only shows that it does not solve any problem, only moves > it elsewhere. Absolutely. Also no programming language solves anything about that. In the end it is the p-n-p transistors which do the job. What is the point? >>> Did I mention that you might want to move you whole hard drive to >>> another machine as well? :-) >> >> Did you try? > > Sure, my USB stick works fine. Because it has FAT, which is supported. >> What happens with a NTFS drive in a Linux system? > > I have no idea since I do not have any NTFS drives around. :-) > > But I do not see how the OO approach would solve that problem. Plug > the OO-aware drive from the OO-aware system from Microsoft into your > OO-aware system of choice and you will be in the same mess. Sure. But your argument was that a file system would handle it better. It does not. > Again, no problem solved. Yes, the only solution of the problem is to write some code. You can write it in assembler, C, Ada etc. But the code must be written. So the problem is how do we write the code, and not whether there should be some. > (because the problem of compatibility is in standardization, not in > paradigm) Standards reduce the number of variants to support. But note that the standards themselves are influenced by the state of the art. Consider POSIX as an example. If there were no UNIX, the standard would be very different. >> But the major problem is lack of any interest, since the market >> of operating system was burnt down to the ground. > > Or maybe the problem is that people try to perceive any given paradigm > as a silver bullet for solving all problems. No. It is because people tend to buy only silver bullets. So whatever you sell, you better do it as such. > I do not think that OO is > one (and I though the industry came to this conclusion some 15 years > ago already). Yep. > Personally, I'm not even sure if I would like to use the OS that was > made pure-OO from the ground up in all possible aspects. Some paradigm > flexibility is needed to find optimal solutions in different > situations and that cannot be achieved if a single idea is driving > everything. What is the opposite paradigm? I don't care much about OO, I do about ADT. The real alternatives are typed vs untyped. I think we have been using the latter for too long and it won't stand up safety and quality requirements of future omnipresent computing. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 14 Jan 2010 05:45 On Thu, 14 Jan 2010 10:12:25 +0100, Jean-Pierre Rosen wrote: > Yes I do. IIRC, the project failed because they completely missed the > point. The processor was intended to be able to check the types of data > at run-time, something that the compiler had already done. In a sense, > it would have been a marvelous processor for any language but Ada - > bringing Ada's type safety to other languages. I disagree. One could perfectly complement another. If you wanted to create a safe OS you would like to protect system objects at the hardware level independently on whether the language does any checks or not. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Jean-Pierre Rosen on 14 Jan 2010 06:31 Dmitry A. Kazakov a �crit : > I disagree. One could perfectly complement another. If you wanted to create > a safe OS you would like to protect system objects at the hardware level > independently on whether the language does any checks or not. > They claimed that the CPU was "putting Ada on silicon". What I mean is that the value of Ada is to check many things at compile time; anything that's on silicon will have to wait until execution time. -- --------------------------------------------------------- J-P. Rosen (rosen(a)adalog.fr) Visit Adalog's web site at http://www.adalog.fr
From: Dmitry A. Kazakov on 14 Jan 2010 08:47
On Thu, 14 Jan 2010 12:31:01 +0100, Jean-Pierre Rosen wrote: > Dmitry A. Kazakov a �crit : >> I disagree. One could perfectly complement another. If you wanted to create >> a safe OS you would like to protect system objects at the hardware level >> independently on whether the language does any checks or not. >> > They claimed that the CPU was "putting Ada on silicon". What I mean is > that the value of Ada is to check many things at compile time; anything > that's on silicon will have to wait until execution time. Well, Ada has a cooperative model of accessing things, i.e. whatever the compiler has checked, that gives no any guaranty at run time. We could also imagine a variant of the language that would give such guaranties if demanded. For example a protected object could be mapped outside the process's space. When calling an operation on it, the OS would check the provided object address and execute the protected operation in the kernel mode. This is how many OSes handle I/O requests. They check the request parameters for being valid addresses in the process space. They also check certain types. When you pass a handle to some system object, it is checked if that is a brush, when used in Paint. That sort of things could be supported by the hardware reducing the overhead of system calls. Shared libraries would certainly win from such design too. So there is nothing wrong in this idea, and it is in no contradiction with static checks. (What iAPX432 was actually designed for is another story) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |