Oakwood compatible modules

[deevans]

Naming the Oakwood modules by anything other than their standardized name (see the Oakwood Guidelines document) fails to utilize them in a useful way. It makes more sense to have these be the default modules, along with the Ofront modules (or even instead of), for the sake of preserving compatibility. (I know the Oberon Report doesn't require any particular modules.)

[dcwbrown]

Yes, it would be nice to have the Oakwood modules with their normal names. The history here is that we have a set of ulm libraries, and they happen to include Oakwood implementations. I'm concentrating on allowing different integer variable sizes at the moment - in particular for many of the libraries to work they need INTEGER to be 16 bit and LONGINT to be 32 bit, and they break on 64 bit builds. I see this as a pre-requisite for supporting Oakwood. David, do you have a view on type sizes? Oakwood has a consistency problem on 64 bit versions in that it specifies that the Files module must store INTEGER as 16 bit and LONGINT and 32 bit - current Vishap builds store INTEGER and LONGINT as the sizes they have in the build, which for 64 bit builds is 32 bit and 64 bit respectively. The least ugly solution I can see is to have a flag in FILES used only in 64 bit builds that says which way to go. (Point being that surely people will want file interoperability between build sizes.)

[deevans]

Isn't general practice that the word size is used for the base type? short/long depends on the needs of the processor. Blackbox for instance has sane settings for Windows 32-bit.

The Report (Oberon not Oberon-2) says that shortint is signed 16-bit. I get the impression that is for 32-bit. Might 32-bit make more sense for 64-bit? The Oberon-2 report seems to concur.

The Oakwood Guidelines are stricter, but again focused on 32-bit. For 64-bit. what is most useful for short? If extra is needed, add to SYSTEM.

[dcwbrown]

Yes, there are two commonly used sets of sizes for SHORTINT/INTEGER/LONGINT and a few other variations too. Oakwood allows for this in 5.2 by giving e.g. MAX(SHORTINT) as 'at least' 127.

However Oakwood does not use the 'at least' language when specifying how values are stored by MODULE FILES files in appendix A. Para 1.2.5.4 says 'In general, all operations must use the following format for external representation ... SHORTINT 1 byte, INTEGER 2 bytes, LONGINT 4 bytes'. This makes sense in that it is important for interoperability - a file written by one implementation will be readable by another. My question is therefore how to implement the FILES module on 64 bit builds. To conform to Oakwood, it would be wrong to write LONGINTs as 64 bits, wouldn't it? And doing so would break file interoperability wouldn't it? Then again some users won't care about interoperability and will want LONGINT to take 64 bits. Would this ever be an issue for you? Do you think it makes sense to have a flag in files selecting between these behaviours?

[deevans]

Would this ever be an issue for you? Do you think it makes sense to have a flag in files selecting between these behaviours?

I think that the Oberon-2 Report and Oakwood Guidelines were made with 32-bit thinking in mind. The 1992 Oberon Report, plus Wirth's adding back FOR in 95/96 is more reasonable to follow for a classic Revised Oberon compiler. I would likely want a 64-bit LONGINT, but perhaps Oakwood modules should remain strictly complied with since voc advertises itself as an Oberon-2 compiler, not an Oberon compiler strictly (compatibility of the -2 extensions may only be compatible under certain conditions). In that case, a SYSTEM.64INT would be fine for me.

How this is decided really comes down to what voc is intending to provide and who its audience is. I personally am uninterested in Oberon-2, and am more interested in Wirth's intent behind his original reports, i.e. exploring his language under platforms other than the Oberon system. (I can see why Oberon-07 went the way it did regarding type inclusion.)

So what does that mean for my issue request? I don't think that OakIn instead of In provides Oakwood compatibility. If the latter is desired, I feel it should be changed to be named as expected.

Perhaps this brings up the larger issue of whether multiple provided libraries for migration is useful. The Ulm compatible libraries are not fully compatible with Ulm 0.5. oo2c might have migration usefulness, but it seems that Oakwood may be the only compatibility a Revised Oberon/Oberon-2 compiler needs. It is unclear to me how successful the Oakwood Guidelines really were as a standardization effort; at least they succeeded in not making the mistakes of M2, or suggesting the way forward.

I hope my comments are useful.

[dcwbrown]

Thanks David, yes that helps.

For the last month or so I have been adapting the compiler to allow compile time selection of integer and set sizes independent of address size. For the old S=8/I=16/L=32 convention I add HUGEINT as 64 bits,and in SYSTEM I provide INT8, INT16, INT32 and INT64.

There are many issues with the library code when built with larger sizes than they were written for. For example there is much real number implementation code that casts (SYSTEM.VAL) between reals, integers, and sets, and which is entirely dependent on their sizes.

The more I try to update the library sources to work correctly with S=16/I=32/L=64 bit integers, the more problems I find and the more messy it gets. Frustratingly these are not the sort of issues that type checking finds.

Your comments are helping me choose to give up on this, and instead make the default integer sizes be 8/16/32 on both 32 and 64 bit compilers. 64 bit integers will be available as HUGEINT.

There will be a compiler option for those wanting larger S, I and L integers (e.g. as in Component Pascal), but this will limit the range of libraries useable.

WRT the Oakwood libraries, I agree. They ought to be available without a prefix to the name, and, given the above thinking, it makes sense to provide them for S=8/I=16/L=32 source code. I think this is achievable.

Many thanks for helping me think this through.

Cheers -- Dave.

[norayr]

I don't know what to do with type sizes.

The idea to fix them and add HUGEINT is indeed appealing. This approach is also what ooc and delpih designers have chosen.

Looks like it won't require library changes, except that we sometimes check SIZE(LONGINT) to 'guess' system architecture, and these changes are doable much easier than fixing all the library modules.

Now let's see other approaches. CP designers decided to not introduce new type, but fixed LONGINT as 64bit even on 32bit machine. For us, it requires a huge effort of changing libraries, and is not appealing.

In O-7, Wirth eventually decided to have one integer type - INTEGER, which is word/pointer size, and LONGINT and SHORTINT are just aliases to it. Indeed, why would anyone need more than one integer type today? The necessity I can think of - to prepare wrappers. Preparing wrappers implies using SYSTEM, then, those types: INT16, INT32, INT64 would have their natural place in SYSTEM.

I've tried to introduce SYSTEM.INT{8,16,32,64}, and as far as I remember I had a lot of internal compiler problems, which I gradually fixed for two weeks, but was unable to fix the last one for another week or two, and eventually gave up.

Also, what if one day I make O-7 compiler work on Linux/x86/x86_64, wouldn't we want it to be able to link our O-7 programs to voc library?

But yes, I understand that fixing the library is much harder effort than fixing type sizes by keeping existing libraries in mind. And also, voc is Oberon-2 compiler. It does not have a duty to provide a library for Oberon-07 compiler.

I also believe that Oberon-2 have proven it's usefulness, that this evolutionary branch is viable, and that is also why we work with/in Oberon-2. And O-7 may not be viable, and appealing to developers.

Thus considering everything above, I also agree, that fixing default integer sizes as 8/16/32 on both 32 and 64 bit architectures and introducing HUGEINT makes sense, and is a feasible way to achieve multiplatform-ness. No wonder delphi designers did the same.

I wonder how GNU team decided differently, i. e. to change long size and make it 64bit long, instead of doing like Microsoft - keeping long 32bit long, and having 64bit long long type.

What I say here, are just thoughts, not more, not less.