[KOS] OCRAM

[Christian G. <ko...@ya...>]

Hi,

is anybody using it? For testing I've added INIT_OCRAM to KOS_INIT_FLAGS 
in the Atari800 DC port
and put the palette values there. I didn't see a noticeable speed 
difference in the screen update.

If you are using it, can you give some first hand experience about 
better (or worse) performance when
using it?


To ease the use of the OCRAM, I've changed the linker script in Atari800 
like this:


@@ -1,3 +1,5 @@
+/* This is the same as KOS's utils/ldscripts/shlelf.xc, except that
+   it adds an "ocram" section.  */
  /* Script for -z combreloc: combine and sort reloc sections */
  OUTPUT_FORMAT("elf32-shl", "elf32-shl",
               "elf32-shl")
@@ -186,6 +188,13 @@
    . = ALIGN(32 / 8);
    . = ALIGN(32 / 8);
    _end = .; PROVIDE (end = .);
+  .ocram 0x7c001000 (NOLOAD) :
+  {
+    *(.ocram)
+    /* We have 8kb of operand cache RAM. The next line lets ld throw
+       an error if we exceed that size.  */
+    . = . > 0x2000 ? 0x2000 : .;
+  }
    /* Stabs debugging sections.  */
    .stab          0 : { *(.stab) }
    .stabstr       0 : { *(.stabstr) }


This way one can define an uninitialized variable to be in the OCRAM 
like this

int var __attribute__((section (".ocram")));

It doesn't work for initialized data as is, that would need changes in 
the startup code.

Anyone interested in this, should I commit this change?

regards,
chris