From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED.2uCIJahv+a4XEBqttj5Vkw.user.gioia.aioe.org!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: is there a version of unix written in Ada Date: Sat, 3 Oct 2020 08:54:32 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <00cd3aaa-d518-43a2-b321-58d6fae70aebo@googlegroups.com> <57eb7a65-51ea-4624-b9dc-9c4dda0fee59n@googlegroups.com> <5f70fd3b$0$13541$426a74cc@news.free.fr> <87wo0d3iac.fsf@nightsong.com> <87sgb02l7b.fsf@nightsong.com> <875z7vyy1u.fsf@nightsong.com> NNTP-Posting-Host: 2uCIJahv+a4XEBqttj5Vkw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 X-Notice: Filtered by postfilter v. 0.9.2 X-Mozilla-News-Host: news://news.aioe.org Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:60397 List-Id: On 02/10/2020 20:34, Brian Drummond wrote: > On Fri, 02 Oct 2020 08:56:44 +0200, Dmitry A. Kazakov wrote: > >> On 01/10/2020 23:36, Brian Drummond wrote: >>> On Wed, 30 Sep 2020 21:42:21 +0200, Dmitry A. Kazakov wrote: > >>>> Static checks must be enforced at run-time. >>> >>> Maybe I should knock together a new Linn Rekursiv on an FPGA. >>> https://en.wikipedia.org/wiki/Rekursiv >>> >>> Objects were essentially memory segments, together with their own >>> object number, type, size : static checks happened in parallel with >>> operations. >>> Even inheritance was handled below the instruction set level (in >>> microcode) >> >> Wow, I newer heard about it. It is pretty close to the general idea. And >> surely SmallTalk is not the right OO model for the stuff. >> >> [UK was leading innovations that time. Inmos' transputers is an >> example.] > > Yes, the transputer was another one. Even before considering parallelism > its single CPU performance (not much talked about) was quite impressive, > considerably higher than the ARM, and much better code density. That time I had an idea of mapping Ada tasks onto individual transputers and using links for rendezvous with marshaling arguments forth and back, alas Inmos died before I even started. > But on OO, Smalltalk was basically what there was, at the time (though > C++ was a contemporary experiment, as was Self, and though I never heard > of it till later, Python. > > The Rekursiv's own language, Lingo, had more familiar syntax than > Smalltalk and could have rivalled Python (though the project died before > my 8086 implementation was complete). > > There was a lot about the processor that could have been improved in a > second pass : as a first attempt it gave a lot away in performance to > concentrate on the fundamentals. > > But it did prove that type safety and dynamic binding are not mutually > exclusive, and that hardware support enforcing at runtime a lot of > correctness [1] that Ada-95 did later at compile time, was possible. Right, Ada 95 OO was ingenious. In combination with visibility based on packages rather than classes, it could be ideal for such type of OS. > It was "huge and complex" by the standards of the day to add e.g. bounds > and type checks in parallel with useful stuff ... like, 70000 gates when > RISC CPUs were 20000. But that would be vanishingly small today. Considering how many cores Nvidia RTX 3080 has.. > [1] Correct if you trusted or separately verified the microcode. A high > integrity Rekursiv would have to prohibit modifying microcode. > > A lot of the ideas you outline here sound quite similar to those of David > Harland, its architect. Maybe they will come back into fashion someday... Yes. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de