<div dir="ltr">Joerg,<br><div>I fully agree with you that this is the classical way in Oberon. But I agree with Walter that, when one deals with lots of low level hardware, it becomes a pain. And the method Walter proposes has lots of advantages in that case. In Ada we have the construct :</div><div><br></div><div>VAR [label] : [type];<br></div><div>FOR [label]'ADDRESS USE [address];</div><div><br></div><div>Yes this is inherently not portable. But then hardware drivers are by nature not portable.</div><div><br></div><div>Already the compiler only accepts certain keywords only when SYSTEM is imported. So I do not see any reason why that mechanism could not be extended by another keyword, IF this is to the good of Oberon and not some useless gimmick that addresses no real problem.</div><div><br></div><div>Regards</div><div><br></div><div>j.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 7, 2018 at 9:13 PM, Jörg <span dir="ltr"><<a href="mailto:joerg.straube@iaeth.ch" target="_blank">joerg.straube@iaeth.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Walter<br>
<br>
Of course one could modify the compiler to accept your proposed syntax:<br>
TYPE Array = ARRAY 30 OF CHAR;<br>
VAR a: Array AT 0FF05H;<br>
BEGIN<br>
a[3] := "f";<br>
<br>
You most probably will agree that the code above is not portable; it will<br>
only run on a HW where this address exists and the underlying data is an<br>
character array.<br>
<br>
With existing Oberon-07, I can reach the same result with the following<br>
statements:<br>
<br>
IMPORT SYSTEM;<br>
TYPE Array = ARRAY 30 OF CHAR; P = POINTER TO RECORD a: Array END;<br>
VAR p: P;<br>
BEGIN<br>
p := SYSTEM.VAL(P, 0FF05H);<br>
p.a[3] := "f";<br>
<br>
As I import SYSTEM, it is immediately visible as being not portable.<br>
<br>
br<br>
<span class="HOEnZb"><font color="#888888">Jörg<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
-----Original Message-----<br>
From: Oberon [mailto:<a href="mailto:oberon-bounces@lists.inf.ethz.ch">oberon-bounces@lists.<wbr>inf.ethz.ch</a>] On Behalf Of Walter<br>
Gallegos<br>
Sent: Tuesday, August 7, 2018 8:34 PM<br>
To: <a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a>; Walter Gallegos <<a href="mailto:walter@waltergallegos.com">walter@waltergallegos.com</a>><br>
Subject: [Oberon] Oberon FPGA hardware point of view<br>
<br>
A FPGA hardware designer point of view;<br>
<br>
In some projects (all my projects) the CPU executes software as<br>
coprocessing; in parallel but outside the main data flow of hardware DSP;<br>
hardware is faster and more efficient than software DSP.<br>
<br>
On this scenery, the memory map could change from one project to another<br>
project. So, hardware/software designers need certain degree of freedom to<br>
access memory mapped areas.<br>
<br>
I propose two modifications :<br>
<br>
1/ Add memory mapped variables<br>
<br>
VAR [label] : [type] AT [address]<br>
VAR [label] : ARRAY [size] OF [type] AT [address]<br>
<br>
In this way we can declare control registers, filters coefficients, data<br>
areas, and so on. In my projects, typical applications are image processing<br>
where the data flow in hardware and the software modify processing<br>
parameters or in digital modulation as ISDB or DVB where software change<br>
modulation and calculates pre-corrector parameters dynamically to reduce the<br>
RF power amp output distortion.<br>
<br>
Many others fast DSP applications use similar architectures where software<br>
calculates filter coefficients, manages user interactions, low speed<br>
communications, etc.<br>
<br>
2/ Make program memory configurable at compiler time.<br>
<br>
I'm using my own version of RISC-5 in VHDL, typically RISC-5 run from BRAMs.<br>
Example from my actual project; FPGA is XC7A35 with 50 BRAMs, used as 16<br>
BRAMs for RISC-5, 27 BRAMs for hardware DSP and 7 BRAMs not used; but,<br>
RISC-5 could use any value from 4 to 32 BRAMs in another project.<br>
<br>
Regards,<br>
Walter<br>
<br>
<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a><br>
<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/<wbr>mailman/listinfo/oberon</a><br>
</div></div></blockquote></div><br></div>