Help with .bss segment overflow

[gama]

Hi, i am working on a new plugin usings the UADE library (http://zakalwe.fi/uade/),
i already have a beta working in the UISIMULATOR but when i try to compile the
code for the sansa fuze v2 i get the following error:

  section '.bss' will not fit in region 'PLUGIN_RAM'
  region 'PLUGIN_RAM' overflowed by 107548 bytes

I have already removed all the unused code, changed some static tables to be allocated
dinamically, and reduced the cpuemu size. But i'm not sure if something else can be done.

If someone would like to help, please let me know, any help would be appreciated.

P.S. Where is PLUGIN_RAM defined?
P.S. Not sure if this is the correct forum to post this  .

gama

[saratoga]

Assuming you don't mind killing playback, you can grab the audio buffer which is essentially all the available memory not used by rockbox (400KB to ~60MB depending on target).  See plugin_get_audio_buffer in plugins.h.

[gama]

Thanks for your answer, but the problem is that i can't even compile the .rock since
i get that error at compile time.  I will try to remove all the static arrays to see if that helps.

There is one big array that takes a lot of space, it's something like this:

Code: [Select]

struct cputbl op_smalltbl_0[] = {
{ op_0_0, 0 }, /* OR */
{ op_10_0, 16 }, /* OR */
{ op_18_0, 24 }, /* OR */
{ op_20_0, 32 }, /* OR */
{ op_28_0, 40 }, /* OR */
{ op_30_0, 48 }, /* OR */
{ op_38_0, 56 }, /* OR */
{ op_39_0, 57 }, /* OR */
{ op_3c_0, 60 }, /* ORSR */
{ op_40_0, 64 }, /* OR */
{ op_50_0, 80 }, /* OR */
{ op_58_0, 88 }, /* OR */
{ op_60_0, 96 }, /* OR */
{ op_68_0, 104 }, /* OR */
{ op_70_0, 112 }, /* OR */
{ op_78_0, 120 }, /* OR */
{ op_79_0, 121 }, /* OR */
{ op_7c_0, 124 }, /* ORSR */
{ op_80_0, 128 }, /* OR */
{ op_90_0, 144 }, /* OR */
{ op_98_0, 152 }, /* OR */
{ op_a0_0, 160 }, /* OR */
{ op_a8_0, 168 }, /* OR */
{ op_b0_0, 176 }, /* OR */
...
{0,0}};

It has around 1800 cputbl structures defined like this:

Code: [Select]

struct {
    func_ptr handler;
    short opcode;
} cputbl;

I was thinking of writing the array data to a file and reading it at
run time, but the problem are the function pointers.

Also i'm not sure if all the m68k opcodes are used by the delitracker players (?),
if only we could recuce the m68k emu size (cpuemu.c).

P.S. i am already using the audio buffer since the whole plugin needs
a couple of MB of memory to work.

P.P.S. If anyone would like to take a look at the code please PM me.  I even have a
devcpp project to test UADE under windows.

[nls]

Allocating empty buffers from the audio buffer should be easy but if that is not enough you probably need to load or generate this data at runtime and fill in the buffer or possilby use the plugi  overlay system but i don't know if that works for all players (see apps/plugins/lib/overlay.[ch]) also if you want people to look at the code it is probably easiest to put it in our patch tracker, that also makes it easier to make relevant suggestions.

[mld]

>Also i'm not sure if all the m68k opcodes are used by the delitracker players (?),
>if only we could recuce the m68k emu size (cpuemu.c).

as for all opcodes, theoretically it can use all of them, since the players are just like any other programm.
As for the instruction sets... I think most of the use the basic 68000 opcodes, some few (AHX, EMSV8 and some customs) use the 68020.
I don't recall one using anything funkier than that.

hmmh, an idea to reduce data would be perhaps to get the source of a simple custom music and check for opcodes used in it and in score and get uade to work by only using them. And so on and so on... a lot of work, tho.

Michael

ps. using a fuze2 here, and I'm willing to testdrive ;-)