[Oberon] FPGA - Bit reversal

[Skulski, Wojciech]

Joerg:

  thank you for a thoughtful answer.

I found a short text on sets on NW page www.inf.ethz.ch/personal/wirth/Oberon/index.html. It is just two pages and feels unfinished. Nevertheless, NW takes a position in favor of bit manipulation using sets. My remarks on BITS went in the same direction. I just remember the simplification which BITS brought to my data processing code when someone pointed it out to me on the BlackBox mailing list.

I also looked at the "Differences between Revised Oberon and Oberon" from the same page. The last section "Miscellaneous" is quite striking to me. I am not sure is renaming ROT into ROR, ENTIER into FLOOR, and other such cosmetic changes is progress. It rather looks like a headache for users of the language who now have to port their programs. Replacing HALT with ASSERT(FALSE) feels plain ugly to my taste. 

All in all it looks to me that Oberon-07 is meant as a microcontroller language. For every feature added two need be deleted. I can understand this approach if one wants to run the compiler and the operating system in a megabyte of RAM. This is an impressive feat and I can presume that the language has to be frugal if the compiler has to fit into such RAM space.

On the other hand, the one megabyte FPGA card just happened to be available. It is not the only possible solution even in the FPGA world. Let me compare memory prices to make it clear. Two 0.5 MB chips type IS61LV25616AL-10TL comprising the 1 megabyte cost $9.26 at DigiKey. A single 512 megabyte chip type AS4C256M16D3LB-12BCN costs $10.59. So we are looking at the cost effectiveness differing by orders of magnitude. 

These are different technologies. One is simple to use, while the other is much harder. On the other hand, boards using the latter have been built. (For example, Arty from Digilent.) It is not that clear to me that the language definition and compiler technology should stay at the level of asynchronous SRAM rather than advance into the era of DDR3L.

Thank you,
Wojtek

________________________________________
From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Jörg [joerg.straube at iaeth.ch]
Sent: Sunday, September 24, 2017 2:06 AM
To: ETH Oberon and related systems
Subject: Re: [Oberon] FPGA - Bit reversal

Wojtek

I think there is a misunderstanding.
Of course I know that bit positions are important. And Oberon can handle those.
But the point is portability. I don‘t talk about assembler code as it is per definition bound to the processor so not portable by definition.

I talk about higher level source code that has to be compiled to the CPU of your choice.

The Oberon complier offers you low level access to CPU dependent functionality. It does this by offering a pseude MODULE called SYSTEM. It’s not a normal module. Whenever you find a source code where this compiler module SYSTEM is imported you have a hint that most probably this code is NOT portable as it either depends on endianess, the underlaying OS Oberon runs on or other low level characteristics that you need to check if xou port your code to another machine.

So SYSTEM is good, as it allows low level bit access and in parallel hints the programmer on possible portability issues.

Now ORD() - as it is now in the Oberon report - is „evil“ as code using it might not work on other machines as it depends on lower layer characteristics (endianness, character encoding  used etc) WITHOUT hinting the programner on possible portability issues. The code compiles but might not work.

BTW: I‘m engineer and hate Windows :-)

Jörg

> Am 23.09.2017 um 15:38 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
>
> Evil?
>
> If you want to manipulate bits, then you cannot escape the fact, they they have their positions within the word. The position depends on a platform. There is no such thing in the world like a computer which would not depend on bit positions. A processor status or setup depends on particular bits within registers, the video or audio depends on particular bits, and so on.
>
> I see this discussion as yet another chasm between computer scientists and engineers. The former want to live in an ideal programming world where algorithms move from place to place without changing anything. For them, bit positions are ugly details to get forgotten. For an engineer the very notion that particular bits are not accessible is a sheer absurd.
>
> I build and program hardware. I deal with bits every day. Anything what hampers my access to bits is an instant enemy. Our friends computer scientists should one day wake up to the fact that hardware has to be controlled by accessing particular bits in particular places. Having good tools for doing this is essential. These tools need to be nurtured rather than frown upon.
>
> I know that Chris is on our side. He programs microcontrollers.  I am talking to the others who still think that Oberon only runs on a Turing machine. Or on Windows.
>
> Thanks,
> W
> ________________________________________
> From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Jörg [joerg.straube at iaeth.ch]
> Sent: Saturday, September 23, 2017 9:03 AM
> To: chris at cfbsoftware.com; ETH Oberon and related systems
> Subject: Re: [Oberon] FPGA - Bit reversal
>
> Chris
>
> I know. ORD() is ‚evil‘ as I wrote in a previous mail. ORD(“S“) is not defined either....
>
> Jörg
>
> Am 23.09.2017 um 14:09 schrieb Chris Burrows <chris at cfbsoftware.com>:
>
>>> -----Original Message-----
>>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
>>> Jörg
>>> Sent: Saturday, 23 September 2017 4:29 PM
>>> To: ETH Oberon and related systems
>>> Subject: Re: [Oberon] FPGA - Bit reversal
>>>
>>> No, I disagree.
>>> So far Oberon isn t bothered with endianess.
>>>
>>
>> I'm not so sure ...
>>
>> VAR
>> s: SET;
>> i: INTEGER;
>>
>> s := {1,2,3);
>> i := ORD(s);
>>
>> What is the value of i?
>>
>> --
>> Chris
>>
>>
>>
>> --
>> 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=4B2lBNnMg6e8jl6b8d0iX7mjv-NmM2atz1sd-qjBKmA&s=oUsJGLb7Alj3Y8Ye9YimCELYn17n7JlBoVpGStl1Aqg&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=4B2lBNnMg6e8jl6b8d0iX7mjv-NmM2atz1sd-qjBKmA&s=oUsJGLb7Alj3Y8Ye9YimCELYn17n7JlBoVpGStl1Aqg&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=aCw6dEJk6JYUR19N17JJGdjMAtv4t80BIeS4j7LLOAQ&s=cAvtf3FxSH1IQmCe8dQHGUMGQv7WkzCu5wEgcj89KSc&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=aCw6dEJk6JYUR19N17JJGdjMAtv4t80BIeS4j7LLOAQ&s=cAvtf3FxSH1IQmCe8dQHGUMGQv7WkzCu5wEgcj89KSc&e=