Shop OBEX P1 Docs P2 Docs Learn Events
Reusing assembly space? — Parallax Forums

Reusing assembly space?

rokickirokicki Posts: 1,000
edited 2006-12-18 21:21 in Propeller 1
So I'm building some large, multi-object code, of which many of the objects will grab a cog permanently and load it up
with some assembly language.

Unfortunately, the assembly language ends up taking "main" RAM space even after the cog is loaded and started. I'd
really like to be able to reuse this space somehow.

Is there any way in SPIN to say, put this assembly language at the highest address possible (or something like that),
and aggregate it with any other so-marked code snippets, so after my cogs are all loaded I can clear and reuse that
chunk of RAM?

Or is the preferred design to have two "versions" of an object, one with the assembly, and one without that
assumes the cog is already launched and running? And then do a two-stage load, the first of which only loads and
sets up the cogs, and the second loads the "real" main that leaves those cogs running and therefore doesn't waste
memory on cog assembly?

Or is there something fundamental I'm missing?

The reason I ask is that it seems to me there is really about 64K of RAM in the propeller (loosely speaking), and
it would be very nice to be able to make more efficient use of it without playing really dirty tricks with the tool.

Comments

  • BeanBean Posts: 8,129
    edited 2006-12-18 18:49
    Rokicki,
    · I was just about to ask the same question.

    · Like you say, once the assembly code is loaded into COG ram, the hub ram (where it was loaded from EEPROM) is really free. But like you, I cannot figure out how to re-use it.

    Bean.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Cheap used 4-digit LED display with driver IC·www.hc4led.com

    Low power SD Data Logger www.sddatalogger.com
    SX-Video Display Modules www.sxvm.com
    Stuff I'm selling on ebay http://search.ebay.com/_W0QQsassZhittconsultingQQhtZ-1

    "USA Today has come out with a new survey - apparently, three out of every four people make up 75% of the population." - David Letterman
  • Mike GreenMike Green Posts: 23,101
    edited 2006-12-18 18:55
    The Propeller OS deals with this issue by including the assembly drivers in the initial load (the OS itself). All the drivers (keyboard, display, I2C/loader) are started and communicate with an API (application program interface) object using a set of pointers to work areas stored at the end of RAM memory. This initial program can call the loader which is running in a cog and the loader can load and start a separate SPIN program which includes the APIs, but not the drivers or initialization routines. This is hard to do with only one 32Kb EEPROM, but on the Hydra or planned Proto Board, it's easy since there's more EEPROM included.

    There is no easy way to reuse the space in HUB memory for something else. If all the assembly objects were grouped together in one source file (object file), you could use the DAT space for buffers, but that would be pretty much it. Another alternative would be for a setup program to write out several 512 word blocks to a 2nd page of EEPROM, one for each cog's contents and the actual program would not have the DAT sections, but would read these in one by one to a HUB RAM buffer, then start up a COG with the buffer contents.

    Post Edited (Mike Green) : 12/18/2006 7:01:00 PM GMT
  • potatoheadpotatohead Posts: 10,261
    edited 2006-12-18 19:28
    Would be nice to define a variable to exist at an address, then let the user figure it out from there.
  • rokickirokicki Posts: 1,000
    edited 2006-12-18 21:21
    Yeah, it's actually interesting because it's not *just* the assembly instructions you want to "free" for reuse
    but also the code that loads them up. A two-phase load makes good sense, but the problem with this is we
    don't have conditional compilation or anything, so it's hard to have one integral "object" that does both
    phases.

    In a way, the OS uses a great approach; you put as much generic infrastructure code as possible into COG
    memory, which means the "application" program gets more memory for its own purposes.
Sign In or Register to comment.