What is the difference between LOCAL memory for programs and LOCAL memory for Direct Commands?

Question

I've learned a bit about Direct Commands in EV3 and understood the work of Local and Global memory. Using the Direct Commands I can access the memory using an offset of the accessing byte/bytes (like if I want to access the byte 4 - I could write smth like LVX(4) (if I use already prepared library)). Now I want to work with .rbf files and found a cool repo that can decompile it into something readable.

And then to this:

Now I really don't understand what is going on. I had some other programs decompiled and as I understood these thing like $LOCAL4 the number in it is directing not to a offset of bytes but bits. There were also some locals like $LOCAL120 and $LOCAL121.
I want to understand is there something common between these local things? And is there docs about memory used by .rbf files?

Answer 1

It looks like the disassembler you used doesn't show the complete picture. Like many programming languages, the lmsasm language allows allocating variables with either a global scope or a local scope.

I wrote a disassembler in Python that will create a .lms file that can be recompiled with the lmsasm assembler. Using this disassembler should show the actual allocations, although not with the correct data types.

To explain it better, consider this example:

DATA32 MyGlobalInt

subcall MySubroutine1
{
  DATA32 MyLocalInt

  // subcall can use both global and its own local variables
  ADD32(MyGlobalInt, 10, MyLocalInt) // MyLocalInt = MyGlobalInt + 10
  ...
}

subcall MySubroutine2
{
  ADD32(MyGlobalInt, 10, MyLocalInt) // ERROR! MyLocalInt is not defined

  // we could define MyLocalInt at the start of this subcall
  // to fix the error, but it would be a new variable, not
  // related to the one with the same name in MySubroutine1
  ...
}

...

Global variables are declared at the top level of the file and can be used in any blocks (subcall, vmthread, etc.) and will have the same value everywhere.

Local variables are declared inside of a block (between curly braces). Those variables can only be accessed in that block and the value does not persist between calls of that block.

---

Direct commands also run as a program. They just have more limited rules compared to a user program.

So, to answer the fundamental question: memory isn't directly shared between programs.

However, there are some opcodes that can be used to access memory in other programs.

From http://ev3.fantastic.computer/doxygen/VM.html:

opMEMORY_WRITE (PRGID, OBJID, OFFSET, SIZE, ARRAY)

Write VM memory

Dispatch status unchanged

Parameters

• (DATA16) PRGID - Program slot number (must be running) (see prgid)
• (DATA16) OBJID - Object id (zero means globals)
• (DATA32) OFFSET - Offset (start from)
• (DATA32) SIZE - Size (length of array to write)
• (DATA8) ARRAY - First element of DATA8 array to write

Direct command example

opMEMORY_READ (PRGID, OBJID, OFFSET, SIZE, ARRAY)

Read VM memory

Dispatch status unchanged

Parameters

• (DATA16) PRGID - Program slot number (must be running) (see prgid)
• (DATA16) OBJID - Object id (zero means globals)
• (DATA32) OFFSET - Offset (start from)
• (DATA32) SIZE - Size (length of array to read)

Returns

• (DATA8) ARRAY - First element of DATA8 array to receive data

Direct command example

---

Using these instructions seems dangerous since one program doesn't really know what is running in the other slot, so you may or may not be reading from the memory you intended to and writing to the wrong memory could cause crashes or other unexpected behavior.

Instead, I would recommend using the mailbox opcodes to transfer information between programs if needed.