[Oberon] Bit manipulation in Oberon-07

[Chris Burrows]

> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> Jörg Straube
> Sent: Sunday, 28 October 2018 4:24 AM
> To: ETH Oberon and related systems
> Subject: Re: [Oberon] Bit manipulation in Oberon-07
> 
> I fully understand that in a Cortex-M compiler there might be the
> need to allow low level access to single assembler instructions of
> that specific CPU.
> 
> So a procedure SYSTEM.UBFX makes sense as the compiler maps it to the
> corresponding Cortex-M CPU instruction.

The reasoning behind SYSTEM.UBFX and SYSTEM.BFI was not to make use of spare instructions. It was motivated by the need it was to be able to manipulate bitfields by bit number (as usually specified in datasheets) without having to do mental gymnastics. The initial idea and the names used were inspired by Cortex-M. 

> 
> (I thought UBFX would need least significant bit number and width. So
> UBFX(7,3) should extract bit 7,8 and 9) and not bit 3..7
> 

We are not trying to emulate the UBFX instruction - perhaps we should have given it a different name to avoid confusion. However we couldn't think of anything short enough that wasn't an acronym so we used the same name that ARM chose.

Datasheets typically do not use the number and width to specify bitfields, they use MSB:LSB so that was what we decided on when designing the procedure call.

e.g. In section 22.6.1 RTC Time Register on Page 583 of the STM32F207 Reference Manual it says that 

  Bits 14:12 MNT[2:0]: Minute tens in BCD format

In Astrobe for Cortex-M I can then simply write the statement:

  SYSTEM.UBFX(mmt, time, 14, 12);

The compiler does the mapping from MSB, LSB to LSB, (MSB-LSB+1) for me and generates the code: 
  
  UBFX r3,r11,12,3

When you are dealing with hundreds of these things it is so easy to make mistakes and so difficult to find them. The closer your code is to the real life representation of the data the better. The more transformations you have to do the more likely you are to make a mistake. The compiler is much more reliable for dealing with these sorts of mapping issues.

> However, I don t like the idea to make this procedure available in a
> RISC5 compiler. In my point of view this goes to far abd can be seen
> as kind of misuse of SYSTEM to emulate CPU instructions of one CPU
> (Cortex M) on another CPU (RISC5).
> 

You'll like the UBFX and BFI instructions in RISC6 then ;-)

> Luckily in this case the bit numbering of Cortex M and the bit
> numbering of RISC5 are identical, both use LSB0. But if one CPU used
> MSB0 and the other LSB0, what is the definition of the UBFX arguments
> then?
> 

That is why it is defined in the SYSTEM module. Any use is potentially non-portable to other architectures. The same argument applies to the existing SYSTEM.BIT Oberon-07 function. 

I have identified 375 occurrences of SYSTEM.BIT in my Cortex-M3 library modules and examples code. However, they are mostly dealing with application-specific peripheral registers as defined by NXP and STM. There's a lot more to worry about than endian issues. Portability is not a realistic aim when working with hardware-defined interfaces,

Regards,
Chris

Chris Burrows
CFB Software
http://www.cfbsoftware.com/RISC5