Astrobe Forum

The code generated by SYSTEM.PUT(irqICER, irqSCBit) is: mov r10, irqICER mov r9, irqSCBit str r9, [r10] or, depending on the value of irqICER, it could be: ldr r10, [pc+offset] <Const:0> mov r9, irqSCBit str r9, [r10] ... <Const:0> irqICER As far as I know that is about as optimal as it could be wit...

Thank you for your example.

bscholte wrote:I am sure one can make a nice iteration to calculate these values,

Yes indeed you can. Look for the Astrobe example called CalcBaudRate in your Astrobe Examples\General folder for an Oberon algorithm to calculate these values.

Thank you for your report. On first sight it appears to be a limitation which I was not aware of. Note that the record parameters in these examples should be VAR parameters, but the problem still remains.

Leaf procedures with POINTER parameters appear to be OK.

The call to P3 is the most efficient (just). The calls to P1 and P2 generate identical code for the reason you state.

That all looks good to me. In this case the assignment: t := t1 is equivalent to: t.i := t1.i t2.k remains unchanged. If you wanted to modify k as well you would need to use an assignment with a type guard (and a type test to be on the safe side) within the procedure P1. PROCEDURE P1(VAR t: T1); VAR...

Good questions! It took some investigation and discussions with colleagues to satisfy myself that the CASE statements in your example are behaving as designed. The EBNF syntax for the CASE statement in the Oberon report, where the subject of a CASE statement is an expression, only applies to the num...

I can recommend an excellent reference to help you to understand the reasoning behind these sorts of details. It is the book titled Object-Oriented Programming in Oberon-2 by Hanspeter Mössenböck. It is available as PDF with the friendly permission of Springer-Verlag from : http://ssw.jku.at/Researc...

Refer to section 10.1. Formal parameters in the Oberon Language Report. In particular: The type of each formal parameter is specified in the parameter list. For variable parameters, it must be identical to the corresponding actual parameter's type, except in the case of a record, where it must be a ...

Here's a loosely related follow-up issue I ran into today: MODULE M1; TYPE T1 = POINTER TO T1Desc; T1Desc = RECORD END; VAR ta: ARRAY 4 OF T1; t: T1; BEGIN CASE ta[0] OF (* 1: does not compile: invalid type *) T1: END; IF ta[0] IS T1 THEN END; (* 2: does not compile: compiler error; reg stack not e...

Oh, that's a bit disappointing. In my book, being able to extend a base type without the need to change this base type scores high. Again, is this a limitation of the language or the compiler? There appears to be some misunderstanding. You can certainly extend a base type without the need to change...