Shop OBEX P1 Docs P2 Docs Learn Events
Assembly Conditions and Error — Parallax Forums

Assembly Conditions and Error

bpiperbpiper Posts: 3
in General Discussion
The conditional statements for this code have not worked, and I have been getting an error: "Expected a constant, unary operator, or "("." on the line "mov clicks,ina". Is there a specific set up I must do to code this in assembly?
spin
spin
Encoder_Test_Serial2.spin
1K

Comments

  • ElectrodudeElectrodude Posts: 1,657
    edited 2016-08-24 20:58
    Spin code can only go in PUB and PRI blocks, and PASM can only go in DAT blocks. You can't put Spin statements in a DAT block like that - Spin is interpreted and doesn't get compiled to assembly.
  • ersmithersmith Posts: 6,053
    If you want to convert some Spin code to assembly, try spincvt.

    I'll also note that you can't access Spin variables declared in the VAR block from PASM code (at least not directly by name).
  • ElectrodudeElectrodude Posts: 1,657
    edited 2016-08-25 03:08
    ersmith wrote: »
    I'll also note that you can't access Spin variables declared in the VAR block from PASM code (at least not directly by name).

    To acces Spin variables from PASM, your Spin code need to pass the cog pointers to the variables, which it can then access with rdlong/wrlong/etc. The easiest way to do this is by defining LONGs at the bottom of your DAT block and having the Spin code set those longs to pointers to variables before starting the PASM cog. You can also use the PAR register discussed in the Propeller manual, but I've generally found that to be more trouble than just poking pointers into the cog image before loading it.
  • User NameUser Name Posts: 1,451
    Electrodude wrote: »
    To acces Spin variables from PASM, your Spin code need to pass the cog pointers to the variables, which it can then access with rdlong/wrlong/etc. The easiest way to do this is by defining LONGs at the bottom of your DAT block and having the Spin code set those longs to pointers to variables before starting the PASM cog. You can also use the PAR register discussed in the Propeller manual, but I've generally found that to be more trouble than just poking pointers into the cog image before loading it.

    Like a rube, I've been using PAR all these years.
    Clearly I've been missing the meetings where cool things are discussed.

  • David BetzDavid Betz Posts: 14,516
    User Name wrote: »
    Electrodude wrote: »
    To acces Spin variables from PASM, your Spin code need to pass the cog pointers to the variables, which it can then access with rdlong/wrlong/etc. The easiest way to do this is by defining LONGs at the bottom of your DAT block and having the Spin code set those longs to pointers to variables before starting the PASM cog. You can also use the PAR register discussed in the Propeller manual, but I've generally found that to be more trouble than just poking pointers into the cog image before loading it.

    Like a rube, I've been using PAR all these years.
    Clearly I've been missing the meetings where cool things are discussed.

    I've used both approaches but you might get into trouble poking values into the image if you're going to load more than one COG with the same image consecutively because the first COG may not have finished booting before you start patching the image for the second COG.

  • ElectrodudeElectrodude Posts: 1,657
    David Betz wrote: »
    User Name wrote: »
    Electrodude wrote: »
    To acces Spin variables from PASM, your Spin code need to pass the cog pointers to the variables, which it can then access with rdlong/wrlong/etc. The easiest way to do this is by defining LONGs at the bottom of your DAT block and having the Spin code set those longs to pointers to variables before starting the PASM cog. You can also use the PAR register discussed in the Propeller manual, but I've generally found that to be more trouble than just poking pointers into the cog image before loading it.

    Like a rube, I've been using PAR all these years.
    Clearly I've been missing the meetings where cool things are discussed.

    I've used both approaches but you might get into trouble poking values into the image if you're going to load more than one COG with the same image consecutively because the first COG may not have finished booting before you start patching the image for the second COG.

    Just have the cog set a flag passed through PAR to tell you it's done booting. Make the flag one of the values you poked parameters into to save a long.
  • David BetzDavid Betz Posts: 14,516
    Electrodude wrote: »
    David Betz wrote: »
    User Name wrote: »
    Electrodude wrote: »
    To acces Spin variables from PASM, your Spin code need to pass the cog pointers to the variables, which it can then access with rdlong/wrlong/etc. The easiest way to do this is by defining LONGs at the bottom of your DAT block and having the Spin code set those longs to pointers to variables before starting the PASM cog. You can also use the PAR register discussed in the Propeller manual, but I've generally found that to be more trouble than just poking pointers into the cog image before loading it.

    Like a rube, I've been using PAR all these years.
    Clearly I've been missing the meetings where cool things are discussed.

    I've used both approaches but you might get into trouble poking values into the image if you're going to load more than one COG with the same image consecutively because the first COG may not have finished booting before you start patching the image for the second COG.

    Just have the cog set a flag passed through PAR to tell you it's done booting. Make the flag one of the values you poked parameters into to save a long.
    Yes, that will work. However, it slows down the boot process for the second COG because it can't run in parallel with the loading of the first COG.

  • ElectrodudeElectrodude Posts: 1,657
    edited 2016-08-26 16:39
    Put the parameters at the very beginning, right after an initial "jmp #actual_code". Reuse the jmp instruction as a variable later, to save a long. Then, forget the done-booting flag and use the Propeller manual or datasheet's timing information and either a tiny waitcnt or the fact that the Spin interpreter is slow to know when it's safe to start the next cog.

    I've never really needed to start the same cog image with different parameters multiple times. The only homogeneous parallel Propeller program I've ever written, a PASM Mandelbrot set renderer, starts all worker cogs with the same parameters, and they then use a lock to arbitrate the allocation of 16-pixel columns among themselves.
  • David BetzDavid Betz Posts: 14,516
    Electrodude wrote: »
    Put the parameters at the very beginning, right after an initial "jmp #actual_code". Reuse the jmp instruction as a variable later, to save a long. Then, forget the done-booting flag and use the Propeller manual or datasheet's timing information and either a tiny waitcnt or the fact that the Spin interpreter is slow to know when it's safe to start the next cog.

    I've never really needed to start the same cog image with different parameters multiple times. The only homogeneous parallel Propeller program I've ever written, a PASM Mandelbrot set renderer, starts all worker cogs with the same parameters, and they then use a lock to arbitrate the allocation of 16-pixel columns among themselves.
    Yes, that trick works as well. You just need to be aware that something like this is necessary otherwise you end up with hard to debug problems.

  • Dave HeinDave Hein Posts: 6,347
    I've put the variables at the beginning also, but for another reason. This makes it easier to work with a binary blob, where you don't have access to the variables in the source code. This allows the binary blob to be used with C code. The variables are initialized by just doing a memcpy from a struct to the starting address plus 4.
  • David BetzDavid Betz Posts: 14,516
    Dave Hein wrote: »
    I've put the variables at the beginning also, but for another reason. This makes it easier to work with a binary blob, where you don't have access to the variables in the source code. This allows the binary blob to be used with C code. The variables are initialized by just doing a memcpy from a struct to the starting address plus 4.
    Yup, I've done that as well. That's the way the XMM drivers are handled in propeller-load.

  • ElectrodudeElectrodude Posts: 1,657
    Dave Hein wrote: »
    I've put the variables at the beginning also, but for another reason. This makes it easier to work with a binary blob, where you don't have access to the variables in the source code. This allows the binary blob to be used with C code. The variables are initialized by just doing a memcpy from a struct to the starting address plus 4.

    I've also done that for large Spin programs that loaded cog images off of an SD card to save space.
Sign In or Register to comment.