September 2016 - Oberon - mailman3.inf.ethz.ch

Re: [Oberon] Oberon Digest, Vol 148, Issue 4
by Søren Renner 11 Sep '16

11 Sep '16

"Hard-coded"? So a configuration file would be better? Why not let the source code be the config file? On Thu, Sep 8, 2016 at 10:00 PM, <oberon-request(a)lists.inf.ethz.ch> wrote: > Send Oberon mailing list submissions to > oberon(a)lists.inf.ethz.ch > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.inf.ethz.ch/mailman/listinfo/oberon > or, via email, send a message with subject or body 'help' to > oberon-request(a)lists.inf.ethz.ch > > You can reach the person managing the list at > oberon-owner(a)lists.inf.ethz.ch > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Oberon digest..." > > > Today's Topics: > > 1. Re: NW programming style (Richard Hable) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 7 Sep 2016 20:09:50 +0200 > From: Richard Hable <informujo(a)aon.at> > To: "John R. Strohm" <strohm(a)airmail.net>, ETH Oberon and related > systems <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] NW programming style > Message-ID: <de4e74eb-37c8-ca94-53c7-361fe519aa9b(a)aon.at> > Content-Type: text/plain; charset=utf-8 > > Am 2016-09-06 um 23:18 schrieb John R. Strohm: > > > So you should lock the users into only the configurations That YOU > > feel are acceptable??? > > What gives you that idea? Applications may support different > configurations of mouse button assignments as they wish. > > But for the operating system these are just buttons without specific > meaning, only to be distinguished by their physical positions on the > mouse. No need to assign potentially misleading names to them. > > > As opposed to letting the user set it up the way HE wants it??? And > > making it easier for him to do so? > > How does referring to mouse buttons by names instead of positions within > source code allow users to set up their own configurations? > > > Seriously, the prohibition against hard-coded magic numbers has been > > established practice for DECADES, and the reasons are WELL-known. > > There's nothing magic about the position of a mouse key. But there seems > to be something wrong with your shift key. ;) > > Richard > > > > ------------------------------ > > Subject: Digest Footer > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon > > > ------------------------------ > > End of Oberon Digest, Vol 148, Issue 4 > ************************************** >

1 0

Re (2): RISC5
by peter＠easthope.ca 11 Sep '16

11 Sep '16

From: Chris Burrows <chris(a)cfbsoftware.com>Sun, 11 Sep 2016 09:32:43 +0930 > ... terminology is RISC-5 not RISC5 ... Corrected. > ... in the summary ... > download a copy from the 'TRM and RISC: FPGA-related Work' > section of Prof Wirth's site: > https://www.inf.ethz.ch/personal/wirth/ Right oh; it's on my reading list. > I might just describe it as 'based on Wirth's RISC Architecture' to minimise > any misconceptions ... Changed that also. "defined by a Verilog text and implemented in a FPGA" is wrong? Wikipedia also lacks an explanation of BRAM. Block or bridging random access? Incidentally, a photo of any of the FPGA systems should fit nicely in the gallery next to glossary. Regards, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

2 1

Re: [Oberon] RISC5
by Chris Burrows 11 Sep '16

11 Sep '16

Not such a trivial question as it turns out. It appears that the correct terminology is RISC-5 not RISC5 as I stated, but it gets more interesting than that. The evolution of Wirth's RISC design is described in detail in the paper titled: "The Design of a RISC Architecture and its Implementation with an FPGA" The answer to your question can be found in the summary of the evolution of the design from RISC-0 to RISC-5 in the introduction. You can download a copy from the 'TRM and RISC: FPGA-related Work' section of Prof Wirth's site: https://www.inf.ethz.ch/personal/wirth/ After re-reading this document I realised that I had misunderstood the meaning of RISC-5 myself. In fact the Astrobe Embedded Project Oberon system is more like a RISC-4 system as it does not need the mouse, keyboard or VGA capabilities. However, it also uses on-chip BRAM (instead of external SRAM) which is an attribute of the RISC-0 design. Except that it is a von Neumann Architecture which is an attribute of RISC-2! I might just describe it as 'based on Wirth's RISC Architecture' to minimise any misconceptions ... Regards, Chris Chris Burrows CFB Software http://www.cfbsoftware.com > -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > peter(a)easthope.ca > Sent: Sunday, 11 September 2016 12:32 AM > To: oberon(a)lists.inf.ethz.ch > Subject: [Oberon] RISC5; was Embedded Project Oberon on a breadboard > > From: Chris Burrows <chris(a)cfbsoftware.com>, Sat, 10 Sep 2016 > 14:54:09 +0930 > > ... ported the Astrobe Embedded Project Oberon RISC5 system ... > > Sorry for a trivial question but I wonder about an acceptable > statement of the meaning of RISC5. > "RISC5, the CPU of Project Oberon 2013, implemented in a FPGA." > What is the significance of "5"? >

1 0

RISC5; was Embedded Project Oberon on a breadboard
by peter＠easthope.ca 10 Sep '16

10 Sep '16

From: Chris Burrows <chris(a)cfbsoftware.com>, Sat, 10 Sep 2016 14:54:09 +0930 > ... ported the Astrobe Embedded Project Oberon RISC5 system ... Sorry for a trivial question but I wonder about an acceptable statement of the meaning of RISC5. "RISC5, the CPU of Project Oberon 2013, implemented in a FPGA." What is the significance of "5"? A glossary section in https://en.wikipedia.org/wiki/Oberon_(operating_system) could be helpful. RISC is mentioned under History but RISC5 could be in a glossary. Comments? Thanks, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

3 3

Re (2): RISC5.
by peter＠easthope.ca 10 Sep '16

10 Sep '16

From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu>, Sat, 10 Sep 2016 17:16:59 +0000 > Pay attention to the fact that RISCV also exists and it is a completely different beast: https://riscv.org/ OK, thanks. https://en.wikipedia.org/wiki/Oberon_(operating_system)#Glossary If anyone can correct it or add another term, certainly do. ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

Re: [Oberon] NW programming style
by John R. Strohm 07 Sep '16

07 Sep '16

--- informujo(a)aon.at wrote: > Am 2016-09-06 um 11:32 schrieb Alexander Ilin: >> You are forgetting that a left-handed person would prefer to have button 3 as the primary button (being under his/her index finger). > > Nope, support for left handers is yet another reason not to give names > like ML, MM, and MR to the mouse buttons, because the left hander will > prefer ML to be on the right side etc. > >> But number 1 is hard-coded. >> Good luck searching for that number to replace it with 3 - which would be a trivial operation with named constants, and could even be loaded from a configuration file. > > Supporting left handers should never require to search and replace every > single reference to a mouse button within application source code. > Instead, a simple flag could be provided to switch between enumerating > the buttons from left to right to the opposite direction. So you should lock the users into only the configurations That YOU feel are acceptable??? As opposed to letting the user set it up the way HE wants it??? And making it easier for him to do so? Seriously, the prohibition against hard-coded magic numbers has been established practice for DECADES, and the reasons are WELL-known.

2 1

CHAR to/from BYTE conversion
by Srinivas Nayak 06 Sep '16

06 Sep '16

We have ORD() and CHR(). ORD() converts CHAR to INTEGER. CHR() converts INTEGER to CHAR. How to convert BYTE to/from CHAR ? Can a CHAR byte hold -ve values? Seems not... BYTE also represents values from 0 to 255. Then what is the difference between BYTE and CHAR? We say, BYTE and INTEGER are compatible; If we assign -12 to a BYTE, what will happen? Kindly help me understanding these. With thanks and best regards, Yours sincerely, Srinivas Nayak Home: http://www.mathmeth.com/sn/ Blog: http://srinivas-nayak.blogspot.in/

12 23

Wikibook _versus_ svn or git.
by peter＠easthope.ca 06 Sep '16

06 Sep '16

Hi, A small discussion about the possibility of a wikibook for the sources for the Oberon system is here. https://en.wikibooks.org/wiki/Wikibooks_talk:What_is_Wikibooks#The_source_c… I began the discussion out of interest. Certainly I don't claim to have any convincing answer or solution. Comments here or on the Wikibook page are more than welcome. Thanks, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

6 7

Oberon-07, recursion and type extension
by Darren Bane 05 Sep '16

05 Sep '16

Can anyone enlighten me as to why the following doesn't work? I've been staring at it for a while to no avail. I always get "incompatible parameters" errors at the recursive calls to Print(). MODULE Family; TYPE ParentDesc = RECORD END; Parent = POINTER TO ParentDesc; SonDesc = RECORD (ParentDesc) wife: Parent END; Son: POINTER TO SonDesc; DaughterDesc: RECORD (ParentDesc) husband: Parent END; Daughter = POINTER TO DaughterDesc; PROCEDURE Write(o: Parent); BEGIN CASE o OF Son: Write(o.wife) | Daughter: Write(o.husband) END END Write; BEGIN END Family. dbane(a)sdfeu.org SDF-EU Public Access UNIX System - http://sdfeu.org

8 10

Re: [Oberon] Oberon-07, recursion and type extension
by John R. Strohm 05 Sep '16

05 Sep '16

--- informujo(a)aon.at wrote: > Actually, a functional-programming expert once said that "recursion is > the goto of functional programming", since most recursive functions can > be replaced by higher-level standard functions like "map" and "filter". Key word: "most". "most" does not equal "all". Again, consider Quicksort.

1 0