Some Clarification

kt88seamp

Hello,

I used to be a regular user of the Propeller until switched over to FPGAs and other controllers such as ARM units. I have learned a great deal more about digital systems since last year when I was actively involved with the Propeller. I have a much greater understanding of how it works, on a low level, now that I succeeded in engineering my own soft processor in VHDL. Now onto my question.

I am trying to directly upload assembly instructions to the EEPROM and have the Propeller execute them. I will tell you what I am doing this for in the projects section as soon as I completely collect all my thoughts for what I will do. It never hurts to plan your projects well. Basically, I am making a software based interpreter for a scripting language I am creating. The compiler for my scripting language will be written in .NET and, depending on my scripting command, will generate at least one propeller assembly instruction per command. Last year I made a crude version of this system with SPIN commands interpreting my script commands, but this was HORRIBLY inefficient.

My goal is to send propeller assembly commands over RS-232 into the Propeller's 32k I2C EEPROM. A spin routine will then receive the commands with FullDuplexSerial and write them to the EEPROM. Once written, the propeller will reboot, load those instructions into a cog and run them. I will do this by sending the entire 4 bytes of the instruction from the C# program (eg 101000 001i 1111 ddddddddd sssssssss for mov).

For example, lets do a mov immediate of the value 0xFFFFFFFF to cog memory address 0x0A. My first question is: It possible to move a literal value into an address without ascribing a name to it, or in the Propeller's case, making it a register? What would be the syntax for that in propeller assembly. I cannot seem to find it documented anywhere.

As soon as this question is answered, I will ask my next.

kuroneko

kt88seamp wrote: »

For example, lets do a mov immediate of the value 0xFFFFFFFF to cog memory address 0x0A. My first question is: It possible to move a literal value into an address without ascribing a name to it, or in the Propeller's case, making it a register? What would be the syntax for that in propeller assembly. I cannot seem to find it documented anywhere.

FWIW, you don't make anything a register. All cog locations are registers (general or special purpose). As for your example, try:

neg $00A, #1

Apologies, I may have misread what you were trying to say. Huge constants (> 511) have to either be loaded from special locations or you have to construct them with code. It's not always as easy as in the example above. However, I don't see (yet) what would stop you from using the variable/constant pool approach.

kt88seamp

So if I did this:

mov $00A, #$FFFFFFFF

It would store the $FFFFFFFF in the next memory location and take twice the amount of clock cycles to execute, since it is too big to fit in 9 bits?

kuroneko

kt88seamp wrote: »

mov $00A, #$FFFFFFFF

It would store the $FFFFFFFF in the next memory location and take twice the amount of clock cycles to execute, since it is too big to fit in 9 bits?

No, it wouldn't even compile. Besides you don't want -1 executed as an instruction (waitvid). What I meant by code is that - as you are not always lucky, e.g. -1 - you'd have to build up a constant, e.g. by using mov[sdi] & Co, e.g. NEGX ($80000000):

mov reg, #1
ror reg, #1

Why can't you reference a register location (which would leave you with 2 longs used but only one long used re: code execution)? You're not suggesting that you only ever send a single instruction from the PC? Or is it difficult to construct the PASM image in the first place?

Another lazy approach (to avoid data execution) would be:

mov     reg, $+2        ' load constant
jmp     #$+2            ' skip data
long    $ABCDEF01

Having a pool after the code section would obviously be the best solution.

kt88seamp

Where in the EEPROM do you recommend I start placing the assembly language program so nothing is overwritten? The Propeller Tool seems to be arbitrary in where it places it. I suppose I could have a routine that checks the EEPROM for empty space but that might be slow if is heavily loaded. Perhaps the last addresses, or are they used for something specific?

kuroneko

kt88seamp wrote: »

Where in the EEPROM do you recommend I start placing the assembly language program so nothing is overwritten?

The PropTool (or rather the boot loader) only touches the first 32K. Even if your (main) program is shorter everything else is cleared. If you have a 64K EEPROM then the upper half is where I'd put the stuff.

kt88seamp

Now, lets say we have a scenereo where I start my program. And I place the program beginning at memory address 0x8000. Would the syntax:

PUB Main

Congnew($8000, 0)

cause the assembly instructions I manually placed into the EEPROM execute?

Heater.

No. Cognew and such use HUB RAM addresses. There is direct access to the EEPROM in the Prop memory space. You will have to use a EEPROM read/write object to fetch those instructions via it's I2C bus into a cog for execution.

Ariba

I think for what you want to do, you need no EEPROM memory. Just place the received instruction in a MainRAM buffer and start the cog from there. A Cog can only be started from MainRAM (also called HubRAM).

Storing in EEPROM makes only sense if you need it to be persistent without power.

Andy

kt88seamp

I think the thing to do is set aside a buffer in the hub memory, read the instructions out of memory into the buffer, then into the instrList array. I do need the instructions available in non-volatile memory.

<code>
PUB Main

long instrList[1024]

' Run I2C EEPROM read routine.

cognew(@instrList, 0)
</code>

Correct me if the syntax for starting the program stored in this array is incorrect. Also, will I run into trouble since the array is greater than 512 bytes, or will the propeller page the second 512 bytes in?

Heater.

Cognew reads 496 longs into cog and then starts it running. There is no problem about a second page. That's all you get.

However a cog running pasm could always load some instructions in some buffer in cog and then run those as an "overlay". Have a search for Cluso's overlay loader.