Re: [f-cpu] back to VHDL

[Juergen Goeritz <goeritz@oekomm.de>]

Hi!

> > > > > I have no intention to provide "unaligned" access
> > > > > (when a word of 2^N bits has a pointer with the N LSB not cleared)
> > > > > because what would happen if the word crosses a page boundary ?...
> > > > *boom* Yes, I know.
> > > Jo gojl, hä hä hä ...
> </Werner quote>
> > Hope you don't bring that restriction to the rest of the system.
> quoting more or less Michael : "is it RISC, ja oder nein ?"

<smiley> Is SIMD equal to RISC? </smiley> 

> > When DMA devices also come with that restriction it may be hard
> > to implement some applications in speed mode without heavy use
> > of memcpy() which may egalize the gain completely ;-)
> 
> when doing DMA, the HW works in "linear" physical addressing mode.
> it's not a good thing (TM) to let the user directly access DMA.
> However, the paging mechanism can make things complex, not the RISC side.
> And we can limit the DMA transfer size to the page lengths. it shouldn't be
> complex...

Just imagine some DMA communication device filling the data you
want to process into memory by some obscure network protocol
(e.g. TCP/IP). Since you don't want to copy the data hence and
forth it must be put already properly aligned by the DMA device.
And this is where you may get stuck if your data format is 64bit
wide and the packet headers (which have been thrown away during
receive) had a variable length. My quick solution was to define
a new network packet format. :-( 

Any hints for improvements?

> > Beside multiplexer complexity I see no problem to allow an
> > unaligned access within a cache line. Problems only occur
> > when you cross the border of the cache line.
> that's totally right. pages ARE aligned on cache line boundaries.
> It just depends on how much HW you can throw in.
> In the beginning i won't allow this because things are
> already complex enough to keep me busy during the next century,
> but in theory it's possible. however, if you organise your data layout
> correctly, it shouldn't even be necessary. All compilers (today)
> align data on their natural boundaries, we can further compress the
> memory footprint by performing data lifelength analysis and sorting
> the resulting patterns with the size (thus filling the holes).
> 
> ie, the following declarations :
>  char a;
>  int b;
>  long long int c;
>  char d;
>  int *e;
>  
> should be sorted to :
>  long long int c;
>  int *e; /* here we don't know if a pointer is 32 or 64 bits,
>             so putting it here is a way to avoid any problem */
>  int b;
>  char a;
>  char d;
> 
> If all data are aligned, there is no hole between them. 

Yes, I agree as long as you have complete control over the
data structures. But what if the data structure is something
you cannot change and is not fitting to the compiler rules?
Hardware registers and DMA structures sometimes do not fit
and it may get about a bit tedious to program around this.

> The problem with unaligned data in a cache line is to determine whether
> the reference crosses a line boundary and whether this will harm 
> future architectural developments. I prefer to play it "safe" now.

I see what you mean and I agree for 'now'.

JG


*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/