Does SPIN bytecode really need to be in SRAM?

jazzed

Reading all the architectural discussions, it occurred to me that SPIN may not actually need to live in SRAM to be executable. What I mean is, Flash is cheaper in terms of chip real-estate than SRAM. I'm not suggesting some re-spin of Propeller to do this, but it seems that would be an easy way to get more program memory for people who don't mind the Flash cycle. Is there anything about SPIN itself that actually uses self-modifying code?

Thanks,
--Steve

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM

Mike Green

The actual Spin byte codes and the internal tables (with the method pointers) are strictly read-only. DAT blocks are sometimes mixed read-only / read-write and, of course, VAR areas are read-write. The compiler would have to be modified to place the read-only stuff in one area of the address space and the read-write stuff in another area. There would also have to be some way of designating a DAT block as read-only so it could be placed in read-only space. Read-write type DAT blocks would need an initial read-only copy that would be copied to read-write space during initialization and VAR space would need to be zeroed as it is now.

jazzed

Thanks Mike.

It seems that even with today's Propeller this means Spin could be run from external mass storage given some interpreter tweaks and the addition of a compiler bytecode offset. I had to add the bytecode offset for JVM to run from EEPROM at address $10000+, so Spin would likely be the same.

BTW: It was a great pleasure meeting you in Rocklin. Thanks for your continued interest in these forums.

Cheers,
--Steve

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM

Dave Hein

Steve, as you know the method table contains 16-bit offsets.· It seems that the trick would be to extend these to a 32-bit value.· Normally, only 15 bits are required since the RAM is only 32K in size.· We could use the most significant bit to indicate that an indirect 32-bit offset should be used, which is stored at the location given the the 15 least significant bits.· The indirect offset could be stored in the DAT section of the object.· The rest is a simple matter of programming.

Edit: I added a smiley just to make sure you understood I was kidding about the simple matter of programming.· The return address on the stack would also need to be coded as an extended address if it was larger than $7fff.· A Spin compiler would need to be developed that could handle the extended addresses also.· In the meantime, A linker could be written to link all of the objects together into one large image.

A binary file for each object·could be generated with the existing compilers by using dummy objects for each object that is included.· The dummy object would contain empty methods and DAT sections in place of the real objects.· Large objects could be compiled with the dummy objects, and then all the object binary files could be linked together -- just like the way a C compiler works.· This could actually be automated with a utility that can produce dummy versions of objects by extracting the constants and PUB lines.· It seems doable, but with a lot of work.

Post Edited (Dave Hein) : 7/3/2010 9:10:48 PM GMT

Mike Green

Something else to think about ... Hub RAM is only 32K while ROM occupies the 2nd half of the address space, but there are no code references to the ROM. If you make a modified Spin interpreter, you could use the sign bit to designate an extended address, perhaps in an EEPROM or Flash Memory. This would apply to the method tables, return addresses in the stack, and the interpreter's program counter. Things like BYTE[noparse][[/noparse] ], WORD[noparse][[/noparse] ], and LONG[noparse][[/noparse] ] could be modified to use extended addresses as well since their operands are 32 bit addresses. These would need to be able to reference ROM, but anything above 64K could reference Flash or EEPROM (or even external SRAM).

jazzed

@Mike

That's very close to what I'm thinking. I'm doing something similar with the Propeller JVM and EEPROM (with a 2KB cache) and it has potential for more than 96K program memory. Hopefully I can use ROM resources at $8000 by relinking, but haven't really tried that yet. Today I set the program start address to $8000 (as written to EEPROM) and ignore the ROM entirely.

If a huge SPIN program is necessary on the order of mega-bytes, a full read/write memory space would be necessary to contain the program environment.

However, a SPIN program that lives in read-only storage could use HUB memory for object references and relocated DAT sections which would (as mentioned before) need some special treatment. Such a program may be limited, but it would not be as limiting as what we have today. Other byte-wide processor types use as much as an 8:1 program/data memory model with no issues. The Propeller JVM may be similarly restricted but that is TBD (to be discovered).

Hopefully whatever Chip is doing for PropII might be leveraged some way for today's Propeller. Meanwhile SPIN's memory footprint restrictions will continue to be a drag on its potential. I still use SPIN, but the alternatives are getting more attractive day by day.

The LMM extensions for SPIN seem great for speedups, and I'll probably use them in the Html Terminal project as that gets further along. However until there is some program memory breakthrough in SPIN, it will remain my straight-jacket. We'll see [noparse]:)[/noparse]

Thanks,
--Steve

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM

Bill Henning

I personally think that a Spin vm re-targeted for VMCOG would be a great idea [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system

jazzed

Bill Henning said...
I personally think that a Spin vm re-targeted for VMCOG would be a great idea [noparse]:)[/noparse]

I absolutely agree with that !

There is definitely a place for more complex hardware as well as something cheap, simple, and somewhat slower to provide a bigger SPIN code solution.

BTW: Dave, your smiley is re-assuring, but I got what you meant without it [noparse]:)[/noparse].

Cheers,
--Steve

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM

Bill Henning

Yet again, we agree [noparse]:)[/noparse]

I think a Spin, that can run bytecodes out of eeprom, cached, in a 128kb eeprom, would be a great idea [noparse]:)[/noparse]

Consider how cognew could be patched to copy the DAT section referenced to a shared 2k buffer in the hub before executing the cognew...

Then, other than the 2KB shared buffer, 30kb would be available for VAR + stack, with up to 128KB for code... something like the JVM you are working on, but spinnified [noparse]:)[/noparse]

jazzed said...

Bill Henning said...
I personally think that a Spin vm re-targeted for VMCOG would be a great idea [noparse]:)[/noparse]

I absolutely agree with that !

There is definitely a place for more complex hardware as well as something cheap, simple, and somewhat slower to provide a bigger SPIN code solution.

BTW: Dave, your smiley is re-assuring, but I got what you meant without it [noparse]:)[/noparse].

Cheers,
--Steve

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system

Cluso99

Yes, the Spin bytecode could reside in external memory. You just need to change the fetching of the bytecode section to fetch from elsewhere. I think it may be rather easy to use 32 bits here (so, something >64KB). Address pushing would need to be 32bit (not quite sure how the bytecodes work as far as this is concerned). Once the ability to reference using 32bits and external bytecode storage, anything can be used - the EEPROM, SPI RAM/FLASH/EEPROM, SRAM latched or unlatched. All this allows any spped variations required, just by changing the fetch mechanism. Be careful though, only 1 cog can access this wothout locks.

Steve (jazzed), this would be another great improvement.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

Bill Henning

I could make a VMCOG with N mailboxes (n = 1..7) and change the spinner to check each mailbox in turn.

Advantage: no locks needed, should be faster than using locks

Disadvantage: longer latency for any specific cog, slower for single client

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system

jazzed

Hi. I took a little break from Html Terminal stuff to investigate running large spin programs from external memory.

While it is clearly possible to execute Spin bytecodes from external memory, today Spin's assumption of 16 bit virtual machine variables like current PC and PC base are a problem. Spin objects are included in the main program as word references where the addresses are kept as words. This primarily prevents a PC > $ffff from being used.

At this point, I conclude it is no longer worth my effort to pursue this. If someone else wants to take up the cause, I wish them luck.

Thanks,
--Steve

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM

heater

Give it up already. ZPU byte codes can do everything Spin byte codes can do. Plus signed/unsigned 32/16/8 bit arithmetic. Plus a 32 bit address space, HUB RAM or external RAM. Plus you can use the GNU C/C++ compiler.

That's not to say that the ZPU virtual machine is optimal for the current Propeller or the Prop II. It's more a question how Spin and it's virtual machine can/should grow in the future.

Sorry, I'm a bit tipsy this evening...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

jazzed

@heater. My turn. I'll be enjoying a Kiwi Souvignon Blanc now [noparse];)[/noparse]

Just for further torture I decided to carry the experiment to a reasonable conclusion.

This is a very restricted version of Spin. Most of HUB RAM could theoretically be
recovered for video buffer, but it would be a big PITA today. With some compiler
changes in the way dat and var are used, this could open up a larger Spin footprint.

The following attachments work with these limits:

Single COG Spin (don't cognew spin) DAT section for PASM cognew should work (works with the VGA_NoDat_Demo) DAT is not usable other than for PASM; VAR sections work fine The string operator will not work (strings are put in code segment) The ? random operator is disabled The ^^ square-root operator is disabled The |< |> decode/encode operators are disabled Spin code size in EEPROM is limited to 32K Code is not guaranteed to work in other cases without programming effort

Procedure for testing:

1. Download VGA_NoDat_Demo.zip and F11 download/run EEPROM. 2. Notice Hello World print speed. 3. Download Spin32_EECACHE.zip and F10 download/run from RAM. 4. Notice Hello World print speed is reduced. 5. Find EepromCache.spin and remove tick marks from lines 279 & 281. 6. Start Spin32_EECACHE with F10 download/run from RAM. 7. Notice Hello World message spits very slowly with non-cached EEPROM access.

Cheers
--Steve

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM

Post Edited (jazzed) : 7/12/2010 1:40:47 AM GMT