[Oberon] Question about Oberon semantics of VAR parameters

[Skulski, Wojciech]

Joerg:

  thank you for the comment. I am interested because the main point of FPGA Oberon is "low level needs" in hardware interfacing. It would be good to know all these little and not so little tricks which make it easier. Good documentation of undocumented features would be great. And keep the name "Undocumented features" as a nice joke;-)

I like your explanation about interfacing with the low level buffers. I hope it is only enabled with the SYSTEM keyword. If so then it is actually a very neat solution just where it belongs.

Thank you,
Wojtek
________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Jörg [joerg.straube at iaeth.ch]
Sent: Monday, December 9, 2019 3:15 AM
To: ETH Oberon and related systems
Subject: Re: [Oberon] Question about Oberon semantics of        VAR     parameters

Wojtek

As Chris pointed out there are other undocumented features in the compiler.
We might collect and document them. In most (if not all) cases you can live without them or program around them. They come in handy if you have certain low level needs.

The current discussed topic is about loosening the strict typing rules. You mentioned ANYREC and ANYPTR; this is a complete opening up of any type checking.
The undocumented feature is something in between: it allows parameter passing of any variable as long as the size fits. This has the benefit that the low layer module offering this capability just sees the passed variable as a specific nbr of bytes. And the higher level module passing the variable declares its logical meaning. But the size of the two involved views of memory must fit. This is better than ANYREC.

BTW: Standard Oberon-07 offers (kind of) ANYREC. The discussed topic could be rewritten as follows:
Kernel.Mod:
ANYREC = RECORD END;
Sector = RECORD (ANYREC) buf: ARRAY 1024 OF BYTE END;
PROCEDURE GetSector*(src: INTEGER; VAR dst: ANYREC);

FileDir.Mod:
FileHeader = RECORD (Kernel.ANYREC)
  mark: INTEGER;
  name: ARRAY 32 OF CHAR;
  aleng, bleng, date: INTEGER;
  ext: ARRAY 12 OF INTEGER;
  sec: ARRAY 64 OF INTEGER;
  fill: ARRAY 672 OF BYTE
END;

With this ANYREC method there is no size checking involved.

Br
Jörg

> Am 09.12.2019 um 05:43 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
>
> Chris:
>
>> There are several more in the Project Oberon compiler. I won't mention the others for fear of alarming you further. If they haven't been of any concern to you yet then there's no need to worry about them now.
>
> I propose that the compiler documentation should always provide a chapter "All undocumented features of this compiler -  please delete this file before opening it".
>
> Cheers,
> Wojtek
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=o_2RMhgfw_bb7SCocmej1qRyQYU-aA6M2kccNE_1kxQ&s=tZld3Y85H0p8hhO3jGRQvvV2rareqkbTGvlrR0QAmd4&e=

--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwIGaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=o_2RMhgfw_bb7SCocmej1qRyQYU-aA6M2kccNE_1kxQ&s=tZld3Y85H0p8hhO3jGRQvvV2rareqkbTGvlrR0QAmd4&e=