Some questions about gcc and xmm

pik33

I wasn't interested in prop-gcc because at first I don't like C I can of course use it when needed, but when not needed I prefer Pascal (on PCs - Lazarus) - assembler ( on PC - Lazarus, too, which allows asm and makes my friends to ask questions like "can a PC be programmed in assembler???" ) - and, in the Propeller environment - Spin which I think there should be PC port of it with cognew starting a new thread on PC

But now I have a P1V with a 1.5 MB (0.5 MB is a framebuffer) easy accessible SRAM to use. To write a long

mov outb, data
mov dirb, addr               'addr has set bit 31
andn dirb, a80000000    ' $8000_0000 constant - dirb[31]:=0

To read a long

mov dirb, addr               ' addr has set bit 30
andn dirb, a40000000    ' $4000_0000 constant - dirb[30]:=0
nop                              ' eventually add nop to give the module some time to make a read, or do something useful here
mov data, inb

Now, it should be possible to use it for a xmm machine

What I need now is some advice where to search - on this forum - the most important informations about how to create a xmm machine using code above which can be compatible with Propeller GCC - if this is possible. Simply: where to start searching.

David Betz

pik33 wrote: »

I wasn't interested in prop-gcc because at first I don't like C I can of course use it when needed, but when not needed I prefer Pascal (on PCs - Lazarus) - assembler ( on PC - Lazarus, too, which allows asm and makes my friends to ask questions like "can a PC be programmed in assembler???" ) - and, in the Propeller environment - Spin which I think there should be PC port of it with cognew starting a new thread on PC

But now I have a P1V with a 1.5 MB (0.5 MB is a framebuffer) easy accessible SRAM to use. To write a long

mov outb, data
mov dirb, addr               'addr has set bit 31
andn dirb, a80000000    ' $8000_0000 constant - dirb[31]:=0

To read a long

mov dirb, addr               ' addr has set bit 30
andn dirb, a40000000    ' $4000_0000 constant - dirb[30]:=0
nop                              ' eventually add nop to give the module some time to make a read, or do something useful here
mov data, inb

Now, it should be possible to use it for a xmm machine

What I need now is some advice where to search - on this forum - the most important informations about how to create a xmm machine using code above which can be compatible with Propeller GCC - if this is possible. Simply: where to start searching.

This may not be as efficient as you'd like since the XMM kernel always accesses external memory through a cache. The XMM drivers simply provide a way to read/write cache lines. This is in the default branch of propgcc. The story is different in the release_1_0 branch which is the one used by SimpleIDE but even there a message is sent to a COG to translate an external address to an address in the cache and at the same time update the cache if necessary. I think Catalina uses an external memory interface that might work for you though. I've never tried writing an external memory interface for Catalina though so you'll have to get help from RossH.

Dave Hein

David, can you elaborate on how the cache mechanism has changed? Did the main cog always need to talk to the XMM driver cog to determine if the data was in the cache, and now it only needs to talk to the XMM driver when there's a cache miss? Is that how it changed? Is there a document that describes how caching works now?

David Betz

Dave Hein wrote: »

David, can you elaborate on how the cache mechanism has changed? Did the main cog always need to talk to the XMM driver cog to determine if the data was in the cache, and now it only needs to talk to the XMM driver when there's a cache miss? Is that how it changed? Is there a document that describes how caching works now?

Yes, the tag and cache line handling was moved into the XMM kernel so the driver no only handles cache line reads and writes. Unfortunately, there is no document describing this although obviously I should write one!

Edit: The driver interface is a slight modification of Chip's P2 SDRAM driver interface.

Dave Hein

It would be nice to document this. It seems like all it requires is a mailbox where a command, block number and hub address are specified. Maybe a block size is needed also, or that might be defined elsewhere since it's a fixed size. This should make it very easy to write a cache driver. I suppose a lock might be needed if the external memory is used for other purposes, such as with an SD card.

jmg

David Betz wrote: »

....The story is different in the release_1_0 branch which is the one used by SimpleIDE but even there a message is sent to a COG to translate an external address to an address in the cache and at the same time update the cache if necessary.

Does this mean two COGs are used, in this memory model ?

I've thought that could be a good idea, for off-chip memory cases, as it allows the memory interface to run separately from the execute engine - such a split approach also allows some added HW to manage parts of the memory fetch, in the cases of P2, or P1V, and memories like SDRAM, QuadSPI, QuadSPI_DDR, and the new HyperBUS(DDR)
( or even P1 + a small CPLD + memory may be practical)

David Betz

jmg wrote: »

Does this mean two COGs are used, in this memory model ?

I've thought that could be a good idea, for off-chip memory cases, as it allows the memory interface to run separately from the execute engine - such a split approach also allows some added HW to manage parts of the memory fetch, in the cases of P2, or P1V, and memories like SDRAM, QuadSPI, QuadSPI_DDR, and the new HyperBUS(DDR)
( or even P1 + a small CPLD + memory may be practical)

There were always two COGs used. One runs the XMM kernel and the other runs the cache driver in the case of release_1_0 or the external memory driver in the case of the default branch. No more COGs are needed than were needed before.