From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: border2.nntp.dca3.giganews.com!backlog4.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!goblin3!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Simon Clubley Newsgroups: comp.lang.ada Subject: Re: Oberon and Wirthian languages (was: Heartbleed) Date: Mon, 21 Apr 2014 13:06:08 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <1ljwj8f.1wqbhvuabsdw1N%csampson@inetworld.net> <51c7d6d4-e3be-44d5-a4ce-f7e875345588@googlegroups.com> <%J32v.70539$kp1.45343@fx14.iad> <8761m535e4.fsf_-_@ludovic-brenta.org> Injection-Date: Mon, 21 Apr 2014 13:06:08 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="e458ff8b81bc0c159989eb0e36c6e372"; logging-data="22785"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19PKNlFR7pM5YDZrYy1DPfUDekjT592nqY=" User-Agent: slrn/0.9.8.1 (VMS/Multinet) Cancel-Lock: sha1:zVj24xWfRxWNhi0SbrRDSd3IGgk= X-Original-Bytes: 6506 Xref: number.nntp.dca.giganews.com comp.lang.ada:185909 Date: 2014-04-21T13:06:08+00:00 List-Id: On 2014-04-19, Ludovic Brenta wrote: > Simon Clubley writes: >>>> What may be a viable option would be if a simpler Wirth style >>>> language existed and whose compiler generated object code compatible >>>> with gcc and used binutils for it's assembling/linking phase. >>> >>> Oberon? >> >> Something based on one of the Oberon variants is _exactly_ the kind of >> thing I was thinking of. I would modify some of the syntax elements to >> make them more Ada like however. >> [Note: There's a Ada language lawyer question below for those of you who like such things. :-)] >> You know, Oberon-14 sounds like a nice name for a new programming >> language. :-) > > The problem I have with Oberon and its descendants is that they removed > the subrange types from Modula-2 (they are similar to Ada's subtypes of > numeric types). Also, TTBOMK, no Wirthian language allows the > programmer to define new numeric types from scratch and make them > incompatible at compile-time (i.e. requiring explicit type conversion). I can't speak for all Wirth style languages, but that's certainly true for Oberon-2 and it was true for things like the dialects of Pascal I have used in the past. In Oberon-2 however, if you create two record types, each with a single INTEGER within the record, then you can't assign one record to the other: obc -o typetest typetest.m "typetest.m", line 25: record type 'rectype2' is needed on the RHS of this assignment > rec2 := rec1; > ^^^^ > This expression has record type 'rectype1' I got round to double checking this today with the very latest version of the the Oxford Oberon-2 compiler, which I wanted to do before posting. You also can't perform a plain assignment which would result in the loss of data by moving a integer into a smaller sized integer. This is unlike how Free Pascal apparently behaves, BTW. From: http://www.freepascal.org/docs-html/ref/refsu5.html |Free Pascal does automatic type conversion in expressions where different kinds |of integer types are used. I'm going by the documentation as I have never used Free Pascal (and after reading the above I'm not exactly motivated to try it now. :-)) The suggestion of a Oberon variant as a base was to choose something as close to C as possible, which would then have some basic Ada style functionality added into it. > According to John McCormick's famous reseach paper[1], the most > desirable features of a programming language are, in order of > importance: > > - Modeling of scalar objects. > Strong typing. > Range constraints. > Enumeration types. > - Parameter modes that reflect the problem rather than the mechanism. > - Named parameter association. > - Arrays whose indices do not have to begin at zero. Agree with all those, and they are something I would want to see in a C replacement language. > - Representation clauses for device registers (record field selection > rather than bit masks). Getting rid of C style masks should be a major goal and the above is required but not sufficient. To remove all the usage cases for C style masks, we would need atomic access to registers when using bit fields and a way to update a specified list of bit fields at the same time (in a read register/modify bitfields /write back to register operation); either in code: atomic using uart0.config1 .flag1 := 0; .enable := 1; .txdis := 0; end atomic; (I'm not too sure about the leading dots however.) or with a Atomic attribute on the register in question. The problem with a Atomic attribute is that the bit fields would be updated in isolation if the statements were separate and this is sometimes _not_ what you want as well as being far less efficient than C style masks. Using the above construct allows you to update a subset of related bit fields as one operation. Language lawyer question time: What I have not checked however is if a record assignment in Ada to a bit field record variable marked as Atomic would result in all the bit fields listed in the assignment being _guaranteed_ to be updated at the same time or whether there would just be a atomic update of each component in isolation. (Unfortunately, as I need my bare metal code to run on a large range of platforms, it's usually written in C so I've not actually tried to write the above construct. Cohen appears to be silent on the issue and the Ada 95 RM didn't help either.) Any Ada language lawyers around who could answer the above question ? > - Higher level of abstraction for tasking (rendezvous rather than > semaphores). Tasking should not be a part of a C replacement language. You want something which is going to be able to replace, in existing applications, libraries written in C. > - Exception handling. > Exception handling would be nice, but it would have to be a local to the current module exceptions model only. How would you push the exception back to the caller when the caller could be written in any language ? Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world