Spin2cpp and external memory

Dr_Acula

I've been doing some experiments with external memory and I think I can define my problem better now and it comes down to a feature request for spin2cpp. I'd be most grateful for thoughts and help

The problem (sorry this isn't one sentence!)
Most of the code for the propeller is written in Spin. In theory this means that with Spin2cpp, most spin code is available in C. However, translating Spin to C uses up more memory, and some historical Spin programs have been written to fill up all the hub memory. The solution is to add external memory, and there are many options including serial ram, flash ram and storing the program on an SD card. Once a program is written to be stored in external memory, there are some Spin objects where it is necessary to store some data in external memory, and to store some data in hub memory, eg screen buffers, and par data passed to a cog. This problem never comes up in Spin as everything is in hub. But for C, we need a way of defining where things get stored. I am trying to work out a syntax that is backwards compatible with Spin, ie you can write a Spin program and run it and the entire program lives in hub, and then you can run the same program and run it through Spin2cpp and it will run from external memory but with some parts of the data stored in hub.

In Spin - no syntax exists for this.
In C, the syntax uses HUBDATA and then a brace and then everything up to the closing brace is in hub, eg

HUBDATA uint8_t tv_driver::dat[] = {

If we add something like "HUBDATA" or "#HUBDATA" to Spin, it will produce a syntax error.
If we use braces, it will work in Spin, but it may cause some confusion as braces are used in Spin for comments and in C for blocks of code.

So - what I am wondering is using some sort of comment syntax that works for both. For Spin, a comment starts with ' and for C it starts with //

One option would be something like

'HUBDATA
...
'END HUBDATA

This works for Spin and for C, it could be translated to

HUBDATA   then some code, then a brace { and then
a closing brace
}

I'm wondering if this could be added somehow as a switch to Spin2cpp, eg with "--extmem" or similar?

Or - another option which is a more generic solution, would be to add a switch to Spin2cpp "--comment"
and that passes through each and every comment into C, probably converting Spin's single quote into C's double slash. And then pass that code through another program to search for //HUBDATA and convert to the correct C syntax. I don't like this one so much though as it requires a second program, and spin2cpp is so nifty the way it does everything in one pass.

That second option is messy. Although one could argue on other grounds that it might be useful to have a "--comment" switch anyway to pass through all the comments in a Spin program?

My preference thus is a switch that is interpreted as a comment in Spin and is interpreted as marking the beginning and end of hubdata in C.

So a question for Eric. What do you think is a simple way of passing through a way of defining data to be stored in hub?

I'm wondering about two types of syntax
one is
'HUBDATA
'END HUBDATA

but the other is a bit more like some of the switches used by BST, eg
'#HUBDATA
'#END_HUBDATA

and I am sure there are other options.

Thoughts would be most appreciated!

ersmith

You can already add {++HUBDATA} comments to Spin code that will be passed through to the C compiler by spin2cpp (spin2cpp pretty much passes through anything inside a {++...} comment. This won't work for the whole DAT block, but it will work for specific variables. You can also embed C functions by adding a {++ ... } block at the end.

Dr_Acula

Brilliant - that sounds perfect!

Dr_Acula

Hi Eric,

I've been testing this out and run into a bit of a syntax problem

In Spin, I want HUBDATA to be ignored eg

VAR
{++HUBDATA}
long myvariable

but I still want myvariable to be used.

In C I want it surrounded by braces. But how do I add the closing brace of a comment in Spin and get this passed through to C as a closing brace that signifies the end of the block of hubdata?

eg, in pseudo code for Spin

VAR 
  {++HUBDATA}
  long myvariable
  {++END_HUBDATA}

passed through to C - not sure of my syntax but something like

HUBDATA {
    int32_t	Myvariable;
   }

is this possible?

ersmith

Actually the syntax looks like:

VAR
  long {++volatile} myvaraible

Unfortunately while this works fine with "volatile", it doesn't work with "HUBDATA" because the variables are class members, and you can't split the class members among different sections (HUBDATA works by changing the section of the attached variable from ".data" to ".hubdata").

There is a work-around, though: you can put all the DAT section into HUB, like so:

DAT {++HUBDATA}
myvariable long 0

This does require splitting the hub and non-hub variables up into separate .spin files, though, so it's a bit of a pain. I'll think about it, I'm not sure if there's a better solution.

Dr_Acula

Thanks for taking a look at this.

The aim is to translate existing spin objects in the obex in the easiest way, so I guess this takes some thinking about. Looking at something like the TV driver object, there is a list of VAR variables that are passed as a par, so they need to be HUBDATA. And there may be big arrays, eg the TV screen buffer, that will be HUBDATA. And there might be the odd variable sitting on its own. And then there are DAT sections.

Some time ago, and this is all very vague as I never wrote it down properly, I had some problems with variables that were in a VAR section and moving the same variables to a DAT section. I can't recall whether it was var to dat or the other way round, but one ran properly and the other didn't. I never worked out why. Maybe one ended up aligned on a long and one didn't. Maybe there was a mix of byte and word declarations. In any case, in an ideal world, it would be better to keep dat sections as dat and var as var as it introduces another possible variable into the complexity of translating obex into C.

I'll keep thinking about this.