June 2018 - Oberon - mailman3.inf.ethz.ch

FPGA - Screen.Mod
by Tomas Kral 26 Oct '18

26 Oct '18

Hi, EDIT (1) I am looking for `Screen.Mod' module (mainly its `Screen.Grub' command) hinted in PO2013 pictures. I have completed early version of `Bitmaps.Mod' supporting basic set of raster operations. I wish to share pictures and code. As we may not post attachments to the forum, I could expose to GitHub, there is also `WikiBook' run by Lyall E. Please advise. Many thanks. -- Tomas Kral <thomas.kral(a)email.cz>

4 15

FPGA Oberon - Definition Module Tool
by thomas.kral＠email.cz 08 Oct '18

08 Oct '18

Hi, I am thinking of a simple tool that could extract definition info from *.Mod and produce respective *.Def file. Definition files can be quickly looked at, to remind a programmer of the interface *.Mod modules export. While on Linux one could use grep $ grep PROCEDURE\ * *.Mod.txt to obtain info at least about procedures, but how about exported types and variables? I am looking for a recommended way how to simply code such a tool, is it a good idea to use `ORP' parser somehow for the task? I prefer to code it simple, does not have to be perfect, but should carry the idea. Tomas

5 11

Numeric CASE vs IF THEN ELSE Performance
by Andreas Pirklbauer 29 Jun '18

29 Jun '18

> The standard branch via register instruction is > > BR,cond [Rn] > > The new variant of this instruction is > > BR,cond PC,[Rn] > > i.e. the target of the branch is computed by adding the > contents of register n to the current program counter. > > Consequently, the average overhead of any selection > in a CASE statement, including range checking, > is now a constant 6 instructions. Just for the record: With the original “standard” branch via register instruction BR,cond [Rn], as currently defined in RISC, that number is a constant 8 instructions. so.. it’s 8 vs 6

1 0

Compiler that targets ARM
by Andreas Pirklbauer 17 Jun '18

17 Jun '18

> Andreas: > .hex is terrible. A much larger size than binary and it needs the > special tool to burn it into flash. Xilinx used to distribute such a > tool named XSPI, but then they discontinued it and built it into > IMPACT, and then they removed it from IMPACT altogether. > There are other tools out there, but this step used to be one > big mess in my experience. > > Wojtek Understood. But I’m not concerned with code file efficiency at this stage. I just want to get going as fast as possible with having the code generator generate ARM Thumb-1 code which I can instantly run. BTW, I have now searched around the various possible options for a board that I can use. So perhaps I end up using an mbed-enabled board anyway, which uses a raw BIN file not a HEX-format, as mentioned earlier by Chris. I just haven’t decided yet..

1 0

Compiler that targets ARM
by Andreas Pirklbauer 17 Jun '18

17 Jun '18

> E.g. when an Astrobe target is an mbed-enabled board, after > it has compiled and linked the code to generate a BIN file > all it has to do is save the output file directly to the drivename > that is mapped to the development board. Got it. Either way, it’s not really complicated it seems. With micro:bit all one has to do is to convert the generated binary to the .hex format format (=the Intel HEX format): http://tech.microbit.org/software/hex-format https://en.wikipedia.org/wiki/Intel_HEX (since I already have various converters as part of the Oberon system building tools, I can just slightly modify Boot.WriteHex to create a version for micro:bit .hex format)

2 1

Compiler that targets ARM
by Andreas Pirklbauer 17 Jun '18

17 Jun '18

> http://microbit.org Seems like a nice way to get started. Just one quick question: Is it true that one simply needs to drag a .hex file (=code file) over to the MICROBIT USB drive and the code downloaded that way just starts running? (because if that’s the case, the code generator and/or linker just needs to output the generated ARM Thumb-1 code in THAT format)

2 1

Re: [Oberon] Numeric CASE vs IF THEN ELSE Performance
by Chris Burrows 16 Jun '18

16 Jun '18

> From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of J > rg > Sent: Saturday, 16 June 2018 8:15 PM > To: ETH Oberon and related systems > Subject: Re: [Oberon] Numeric CASE vs IF THEN ELSE Performance > > For the special case of Soundex, neither IF-THEN nor CASE are perfect > as we don t want to execute statements per character Well, yes, but that is a discussion for another day. The subject of this discussion is "Numeric CASE vs IF THEN ELSE Performance". If you are interested in "The most efficient way to implement the Soundex algorithm" you might well find it here: https://www.rosettacode.org/wiki/Soundex > > BTW: the runtime behaviour of the IF implementation can be optimized > a little bit by rearranging the different IFs / ORs by taking the > letter frequency into account. (vowels: 49%, dental-mute: 13%, > guttural: 12%, nasal: 9%, labial: 7%, dental-fricative: 6%, palatal: > 4%). > The code size can shrink a little by using an ELSE to combine the > eight gutturals. > Agreed. It is always possible to optimise an IF-THEN-ELSE sequence that has different probabilities of selection. However, there may be other reasons why you might want to order the choices in a particular way. With a CASE statement you can order the selections in the most natural way without being forced to use a particular sequence because of efficiency concerns. That reminds me of one of my favourite cartoons (Frank and Ernest). He was boasting that he had made it easier to find streets by putting them in alphabetic order ;-) Fifth Street First Street Fourth Street Second Street Third Street Regards, Chris Burrows CFB Software http://www.astrabe.com

1 0

Compiler that targets ARM
by Andreas Pirklbauer 16 Jun '18

16 Jun '18

> All the details of what is available is on our Astrobe website Thx. So far, I wasn’t really familiar with the details of the work that you are doing - mainly because a) your dev platform runs on Windows, and b) my disdain for the complexity of the various ARM processor families. But sounds like you’ve been at this for some time … > but one that is particularly interesting is > the BBC micro:bit board: http://microbit.org Interesting. Thx for the pointer. I like the fact that it is so tiny. > Be warned however that ARM Thumb-1 instruction set has > some significant restrictions compared to ARM Thumb-2 or RISC5 ARM Thumb-1 may do for the time being. For now. I only want to see how *fast* I can port my N-th compiler backend correctly. Prof. Wirth once said he did the ARM port “in about a month or so over Christmas” - although I can’t remember which one, but he may (?) have been referring to the DECStrongARM DS1035 used in his model helicopter project back some 20+ years ago . Well, this means it’ll take me at least 2-3x that ;-) Or more...

2 1

Numeric CASE vs IF THEN ELSE Performance
by Andreas Pirklbauer 16 Jun '18

16 Jun '18

> I'll post a message on the Astrobe Forum and this mailing > list when it is available. Ok. We can compare notes then. I have carried forward the implementation of the numeric CASE statement from Ceres Oberon to FPGA Oberon (but of course using the regular BR instruction, i.e. using BR,cond [Rn] and not BR,cond PC,[Rn]). If the performance with your *modified* BR instruction really is demonstrably better AND the new instruction becomes part of the RISC instruction set, then it is perhaps worth making the implementation of the numeric CASE available to everyone. -ap

3 2

Compiler that targets ARM
by Chris Burrows 16 Jun '18

16 Jun '18

> -----Original Message----- > From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of > Andreas Pirklbauer > Sent: Friday, 15 June 2018 11:11 PM > To: ETH Oberon and related systems > Subject: [Oberon] Modified Oberon-07 compiler adding the numeric CASE > statement > > PS: Do you have an Oberon compiler that targets ARM? > Yes - several. We have been developing, selling, supporting and maintaining ARM Oberon embedded software development systems for the last 10 years. 'targets ARM' is too general a phrase as there are numerous ARM architectures currently in use. Our first target was the ARM7 instruction set for NXP LPC2000 processors in 2008. We rewrote the code generator to target the ARM Thumb-2 instruction set for NXP ARM Cortex-M3 microcontrollers in 2012, and then added support for the hardware FPU instructions for the NXP and STM ARM Cortex-M4 and Cortex-M7 microcontrollers in 2014. All the details of what is available is on our Astrobe website: http://www.astrobe.com If you: a) Want to implement a new ARM Oberon compiler target b) Prefer to avoid 'reinventing the wheel' c) Like a challenge then a useful project would be modify the RISC5 Oberon code generator and linker to target the ARM Thumb-1 instruction set as used in the ARM Cortex-M0 processors. There are a large number of inexpensive board available but one that is particularly interesting is the BBC micro:bit board: http://microbit.org It is aimed at school students and there are claimed to be more than 1 million devices already deployed. Be warned however that ARM Thumb-1 instruction set has some significant restrictions compared to ARM Thumb-2 or RISC5 * Most instructions are only 16-bit * There are fewer registers generally accessible * There is no FPU. Before you start, read the book: "The Definitive Guide to the ARM Cortex-M0" by Joseph Yiu, Regards, Chris Burrows CFB Software http://www.astrobe.com

1 0