About SYSTEM procedures

[u/Outdoordoor]

The Programming Language Oberon document gives very limited descriptions of these procedures. Could anyone, please, explain what they do more clearly, and/or correct my guesses about what they do?

I'm specifically interested in these:

• GET(a, v) -- I guess it gets the value at address a and puts it into v?
• PUT(a, x) -- it puts value of x at the address a?
• LED(n) -- from description it sounds like it does anything only when LEDs are accessible, so probably not relevant when working on normal PCs?
• VAL(T, n)
• COND(n)

[u/hobbestherat]

Yes, you got it right. Note: in this notation of GET and PUT the read/written data size depends on the type you read/write which can be a source of unexpected behavior.

[u/hobbestherat → u/hobbestherat]

On the phone I couldn't scroll while the keyboard is open, VAL reinterprets the value as a different type. Not sure about COND.

[u/Outdoordoor → u/hobbestherat]

Thanks for clarifying!

[u/AphidConsulting]

I'm afraid I don't have a tremendous amount to contribute to the conversation beyond saying that I've really only recently gotten into Oberon as sort of a tangent to my Pascal interests, but it seems like a very, very well-designed language.

That's all :)

[u/Outdoordoor → u/AphidConsulting]

True, I've been enjoying using it as well, especially for its simplicity. It took some getting used to, since I'd mainly used C++ before that, but in the end I find it really nice and cozy

[u/suhcoR → u/Outdoordoor]

since I'd mainly used C++ before

That's interesting. I'm still using C++ (though an old version) to implement my Oberon tools, and currently I implement my Micron language which is supposed to be an "Oberon with the power of C" including some C++ features which I appreciate, though simplified to the bare core idea.

[u/Outdoordoor → u/suhcoR]

I saw your Micron project, and it looks quite nice, I'm looking forward to it.

I also had this idea about system-level version of Oberon, so I'm currently learning how to make compilers/interpreters by making an Oberon-07 compiler in C.

As for C++, it's still the language I use most, and I like a lot about it (really missing templates in Oberon/C), but I've started to feel some fatigue with how big and complex it is. Feeling that you can never fully know and understand the language is a bit discouraging. So small languages like Oberon are a nice break from it

[u/suhcoR → u/Outdoordoor]

I've started to feel some fatigue with how big and complex it is

Understandable, particularly because they made it an ever moving target with a commitee full of revolutionary ideas each three years which causes the compiler writers to exhaust and compiler to become incompatible. Using LeanQt core with C++ can essentially do everything C++11 brought to the table, but using the much less complex C++98; I don't even use all of the latter features. When something is good it should just be left untouched, not "optimized to death". At least the C++ standards stay committed (so far) for strict backward compatibility, which allows me to just ignore the madness.

[u/Outdoordoor → u/suhcoR]

Compatibility is one of the things I really appreciate about C++. Sure, it leads to garbage accumulating in the language, which is a big problem. But after something like trying to build a Python project which somehow requires 5 different language versions, I appreciate that I can take C++ code from 10 years ago and just compile it.

[u/suhcoR → u/Outdoordoor]

making an Oberon-07 compiler in C

Oberon-07 is a very nice target to start compilers, mostly because Wirth kicked out even more things which cause complexity in the compiler (such as e.g. non-local variable/parameter access from nested procedures). Unfortunately there is pretty little existing code in Oberon-07 for testing. With Oberon-90 you have hundereds of modules in the Oberon System 3 source tree alone.

[u/Outdoordoor → u/suhcoR]

Well, since it's my first compiler, I'll be happy if it just works in general, so what little code exists should be enough. Also, if I understand correctly, Oberon-07 is basically a subset of older Oberon versions, so I can later add features from Oberon-90 to the compiler and test it against the Oberon System

[u/suhcoR → u/Outdoordoor]

It's not really a subset, but has partly a different philosophy (e.g. return as part of the block syntax, not a stand-alone statement, etc.). It is possible though to construct a language which is compatible with different Oberon versions (as I e.g. did with my Oberon+). People usually (mis)understand Oberon-07 as Wirth's official successor of Oberon 90, but actually it was more about reducing his effort for his FPGA based Risc-5 processor and system. Also note that the language report is incomplete (e.g. the VAR ARRAY OF BYTE backdoor is not documented).

[u/Outdoordoor → u/suhcoR]

I see, that's interesting. What is the VAR ARRAY OF BYTE backdoor?

[u/suhcoR → u/Outdoordoor]

The Oberon 90 language reports specifies it as:

Module SYSTEM exports the data type BYTE. No representation of values is specified. Instead,
certain compatibility rules with other types are given:
1. The type BYTE is compatible with CHAR and SHORTINT.
2. If a formal parameter is of type ARRAY OF BYTE, then the corresponding 
    actual parameter may be of any type.

The 2. point is the "VAR ARRAY OF BYTE backdoor". SYSTEM offers some more backdoors where you can do pointer arithmetics and other nasty but necessary stuff for system development (just without typechecking support by the compiler). In Micron and Oberon+, these features are official part of the language (not backdoors) with type checking support.

[u/Outdoordoor → u/suhcoR]

That's cool, didn't know about it. By the way, what would be the best resources to learn about Oberon in more detail? Apart from language reports and Wikipedia