[Oberon] FPGA - LONG WORD memory access

[Jörg]

See inline
Jörg

> Am 30.04.2017 um 11:31 schrieb Tomas Kral <thomas.kral at email.cz>:
> 
> Hi Joerg,
> 
> Thank you for the example, it nicely confirms what I observed without
> much knowing while toying with Bitmaps.
> 
> Few more questions.
> 
> [a] Is there a timing penalty for accessing bytes rather than longs?
Yes and no. No, as the LDW and LDB instruction uses the same amount of CPU cycles. Yes, as you need four LDB instructions to get the same result as one LDW.
> 
> [b] Oberon, structures, memory blocks, strings, etc, are aligned on
> long word (integer) boundary? Filling and padding over non MOD 4 parts?
The alignment and filling is generated by the compiler.
> 
> [c] Words as such are not implemented (possibly they are not really
> needed), programatically that would require reading longs, and
> * {0..15} masking upper or * {16..31} lower parts, plus some shifts
> ASR/ASL. As that would complicate type conversions. 

That's right. If your program needs 16 bit entities (e.g. an IP stack) you need to do some bit manipulations. But for e.g the IP stack, in most cases I use INTEGERs (iso SETs) and do "MOD 10000H" or "DIV 10000H" to get the upper or lower part. For bitmap handling, HW chip programming or where ever single bits are of value, SETs are the ideal instrument.
> 
> Tomas
> 
> On Thu, 27 Apr 2017 17:50:45 +0200
> Jörg <joerg.straube at iaeth.ch> wrote:
> 
>> Tomas
>> 
>> If you want to understand how the RISC5 accesses the memory, you can
>> look at the Verilog files.
>> - The RISC5.v implements the CPU
>> - RISC5Top.v implements the CPU's environment (memory, peripherals...)
>> 
>> The CPU (RISC5.v) outputs the variable "adr" to RISC5Top. The task of
>> RISC5Top.v is to read the memory at address "adr". The following
>> statement calculates the address for the static RAM:
>> 
>>   assign SRadr = dspreq ? vidadr : adr[19:2];
>> 
>> As you can see, the last two bits adr[1:0] are ignored, so "SRadr" is
>> only a multiple of 4 even in case the "adr" is odd.
>> 
>> You can verify this with the following program
>> 
>> MODULE Test;
>> IMPORT S := SYSTEM, Out;
>> VAR
>>  p, i: INTEGER;
>> BEGIN
>>  p := S.ADR($0001020304050607$);
>>  S.GET(p, i); Out.Int(i, 10); Out.Ln; INC(p);
>>  S.GET(p, i); Out.Int(i, 10); Out.Ln; INC(p);
>>  S.GET(p, i); Out.Int(i, 10); Out.Ln; INC(p);
>>  S.GET(p, i); Out.Int(i, 10); Out.Ln; INC(p);
>>  S.GET(p, i); Out.Int(i, 10); Out.Ln; INC(p);
>> END Test.
>> 
>> Four times the same value is printed (as "p" is handled MOD 4) and
>> only the last line prints the next value in the ARRAY.
>> 
>> Jörg
>> 
>> 
>> -----Original Message-----
>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
>> Chris Burrows
>> Sent: Donnerstag, 27. April 2017 14:16
>> To: 'ETH Oberon and related systems' <oberon at lists.inf.ethz.ch>
>> Subject: Re: [Oberon] FPGA - LONG WORD memory access
>> 
>>> -----Original Message-----
>>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
>>> Tomas Kral
>>> Sent: Thursday, 27 April 2017 6:34 PM
>>> To: Oberon@
>>> Subject: [Oberon] FPGA - LONG WORD memory access
>>> 
>>> Hi,
>>> 
>>> Is allowed to address 4byte integers on odd memory address, or does
>>> it have to be on even boundaries only, aligned on MOD 4?
>>> 
>>> I remember from other platforms, namely 68K, words or longs on even
>>> address only.
>>> 
>> 
>> Your question is answered in Section 17.1 "The SRAM memory" of the
>> project Oberon documentation i.e:
>> 
>> "The selection of the byte affected is determined by address bits 0
>> an 1 (which are ignored in the case of word-access)."
>> 
>> Regards,
>> Chris Burrows
>> CFB Software
>> http://www.astrobe.com
>> 
>> 
>> 
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
>> systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
>> 
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
>> systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
>