Shop OBEX P1 Docs P2 Docs Learn Events
SimpleIDE C Output Tokens or Native?? — Parallax Forums

SimpleIDE C Output Tokens or Native??

greybeardgreybeard Posts: 65
in Propeller 1
Does the C/C++ compiler generate/download native machine code or does it generate/download tokenized code aka SPIN tokens for the interpreter?

Just curious.

Comments

  • DavidZemonDavidZemon Posts: 2,973
    In LMM modes (lmm and all xmm*), it generates native assembly. In CMM, it generates custom 8-bit instructions that are then interpreted in a similar fashion to Spin (this means smaller code size for large projects, but larger code size for small projects because of the interpreter overhead)
  • David BetzDavid Betz Posts: 14,511
    DavidZemon wrote: »
    In LMM modes (lmm and all xmm*), it generates native assembly. In CMM, it generates custom 8-bit instructions that are then interpreted in a similar fashion to Spin (this means smaller code size for large projects, but larger code size for small projects because of the interpreter overhead)
    Actually, the overhead for LMM, XMM, and CMM are about the same. They all make use of a COG running a "kernel". In the case of CMM, the kernel interprets the bytecodes of the CMM virtual machine but it doesn't take up more space in doing that. However, all of the C kernels take up more space than Spin since its interpreter is in the Propeller ROM and doesn't take up any hub memory. Later versions of PropGCC attempt to recover the space for the kernel by adding it to the heap after loading it into a COG but that space is not available for more program code, only dynamically allocated data.

  • DavidZemonDavidZemon Posts: 2,973
    David Betz wrote: »
    DavidZemon wrote: »
    In LMM modes (lmm and all xmm*), it generates native assembly. In CMM, it generates custom 8-bit instructions that are then interpreted in a similar fashion to Spin (this means smaller code size for large projects, but larger code size for small projects because of the interpreter overhead)
    Actually, the overhead for LMM, XMM, and CMM are about the same. They all make use of a COG running a "kernel". In the case of CMM, the kernel interprets the bytecodes of the CMM virtual machine but it doesn't take up more space in doing that. However, all of the C kernels take up more space than Spin since its interpreter is in the Propeller ROM and doesn't take up any hub memory. Later versions of PropGCC attempt to recover the space for the kernel by adding it to the heap after loading it into a COG but that space is not available for more program code, only dynamically allocated data.

    Wow! I didn't realize the LMM kernel was so large. A very basic LMM kernel can be implemented with just four instructions right? read from PC -> execute -> increment PC -> loop
    What features is the above 4-instruction kernel missing that take up so much more memory?
  • David BetzDavid Betz Posts: 14,511
    DavidZemon wrote: »
    David Betz wrote: »
    DavidZemon wrote: »
    In LMM modes (lmm and all xmm*), it generates native assembly. In CMM, it generates custom 8-bit instructions that are then interpreted in a similar fashion to Spin (this means smaller code size for large projects, but larger code size for small projects because of the interpreter overhead)
    Actually, the overhead for LMM, XMM, and CMM are about the same. They all make use of a COG running a "kernel". In the case of CMM, the kernel interprets the bytecodes of the CMM virtual machine but it doesn't take up more space in doing that. However, all of the C kernels take up more space than Spin since its interpreter is in the Propeller ROM and doesn't take up any hub memory. Later versions of PropGCC attempt to recover the space for the kernel by adding it to the heap after loading it into a COG but that space is not available for more program code, only dynamically allocated data.

    Wow! I didn't realize the LMM kernel was so large. A very basic LMM kernel can be implemented with just four instructions right? read from PC -> execute -> increment PC -> loop
    What features is the above 4-instruction kernel missing that take up so much more memory?
    Take a look at the code in the PropGCC repository. It is probably true that the CMM and XMM kernels are somewhat bigger than the LMM one but they all take up space unlike the Spin interpreter which is in ROM.

  • ElectrodudeElectrodude Posts: 1,621
    Would it be possible to make PropGCC target the Spin Interpreter? There is a way to make the Spin Interpreter operate on arbitrarily placed objects, so C++ would also work well on it.
  • DavidZemonDavidZemon Posts: 2,973
    David Betz wrote: »
    Take a look at the code in the PropGCC repository. It is probably true that the CMM and XMM kernels are somewhat bigger than the LMM one but they all take up space unlike the Spin interpreter which is in ROM.

    That's a scary proposition. GCC is huge.... where would I even start? Or is there no short/easy answer to my question?
  • Heater.Heater. Posts: 21,230
    Electrodude.

    Having a C language target Spin bytecodes is something Parallax wanted to do a few years back. There are issues with unsigned numbers and other things so the idea was not to support all C features. It would have been a "not C" C like language. Mostly the forum did not like the idea.

    Then we got Catalina and prop-gcc...

    prop-gcc has it's own CMM code target for smaller code generation and the Prop II does not have the Spin byte code interpreter built in. So I guess targeting Spin byte codes is even less attractive.
  • David BetzDavid Betz Posts: 14,511
    Electrodude wrote: »
    Would it be possible to make PropGCC target the Spin Interpreter? There is a way to make the Spin Interpreter operate on arbitrarily placed objects, so C++ would also work well on it.
    That could possibly be done. One reason it was never attempted is that the Spin VM is not documented. There have been a number of attempts by forum members to document it but there is no official Parallax document describing it. If such a document was made available, a new GCC backend would have to be written. One problem is that GCC kind of expects a register-based machine and the Spin VM is a stack machine. That wouldn't prevent a backend from being written but it would be a problem to be overcome.

  • DavidZemonDavidZemon Posts: 2,973
    Cool :) two good answers to a question I've been wondering recently too!
  • David BetzDavid Betz Posts: 14,511
    Heater. wrote: »
    Electrodude.

    Having a C language target Spin bytecodes is something Parallax wanted to do a few years back. There are issues with unsigned numbers and other things so the idea was not to support all C features. It would have been a "not C" C like language. Mostly the forum did not like the idea.

    Then we got Catalina and prop-gcc...

    prop-gcc has it's own CMM code target for smaller code generation and the Prop II does not have the Spin byte code interpreter built in. So I guess targeting Spin byte codes is even less attractive.
    Maybe we could get Parallax to create a new version of the Propeller chip that has the CMM interpreter in ROM instead of the Spin interpreter. :-)

  • DavidZemonDavidZemon Posts: 2,973
    David Betz wrote: »
    Heater. wrote: »
    Electrodude.

    Having a C language target Spin bytecodes is something Parallax wanted to do a few years back. There are issues with unsigned numbers and other things so the idea was not to support all C features. It would have been a "not C" C like language. Mostly the forum did not like the idea.

    Then we got Catalina and prop-gcc...

    prop-gcc has it's own CMM code target for smaller code generation and the Prop II does not have the Spin byte code interpreter built in. So I guess targeting Spin byte codes is even less attractive.
    Maybe we could get Parallax to create a new version of the Propeller chip that has the CMM interpreter in ROM instead of the Spin interpreter. :-)

    I like it! P1v if nothing else I suppose. Would this allow more than 64 instructions in fcache?
  • David BetzDavid Betz Posts: 14,511
    DavidZemon wrote: »
    David Betz wrote: »
    Heater. wrote: »
    Electrodude.

    Having a C language target Spin bytecodes is something Parallax wanted to do a few years back. There are issues with unsigned numbers and other things so the idea was not to support all C features. It would have been a "not C" C like language. Mostly the forum did not like the idea.

    Then we got Catalina and prop-gcc...

    prop-gcc has it's own CMM code target for smaller code generation and the Prop II does not have the Spin byte code interpreter built in. So I guess targeting Spin byte codes is even less attractive.
    Maybe we could get Parallax to create a new version of the Propeller chip that has the CMM interpreter in ROM instead of the Spin interpreter. :-)

    I like it! P1v if nothing else I suppose. Would this allow more than 64 instructions in fcache?
    Probably not because the CMM interpreter would still take up the same amount of COG memory. It just wouldn't consume any hub memory.

  • DavidZemonDavidZemon Posts: 2,973
    David Betz wrote: »
    DavidZemon wrote: »
    David Betz wrote: »
    Heater. wrote: »
    Electrodude.

    Having a C language target Spin bytecodes is something Parallax wanted to do a few years back. There are issues with unsigned numbers and other things so the idea was not to support all C features. It would have been a "not C" C like language. Mostly the forum did not like the idea.

    Then we got Catalina and prop-gcc...

    prop-gcc has it's own CMM code target for smaller code generation and the Prop II does not have the Spin byte code interpreter built in. So I guess targeting Spin byte codes is even less attractive.
    Maybe we could get Parallax to create a new version of the Propeller chip that has the CMM interpreter in ROM instead of the Spin interpreter. :-)

    I like it! P1v if nothing else I suppose. Would this allow more than 64 instructions in fcache?
    Probably not because the CMM interpreter would still take up the same amount of COG memory. It just wouldn't consume any hub memory.

    Oh... right. Bummer :/
  • David BetzDavid Betz Posts: 14,511
    DavidZemon wrote: »
    David Betz wrote: »
    DavidZemon wrote: »
    David Betz wrote: »
    Heater. wrote: »
    Electrodude.

    Having a C language target Spin bytecodes is something Parallax wanted to do a few years back. There are issues with unsigned numbers and other things so the idea was not to support all C features. It would have been a "not C" C like language. Mostly the forum did not like the idea.

    Then we got Catalina and prop-gcc...

    prop-gcc has it's own CMM code target for smaller code generation and the Prop II does not have the Spin byte code interpreter built in. So I guess targeting Spin byte codes is even less attractive.
    Maybe we could get Parallax to create a new version of the Propeller chip that has the CMM interpreter in ROM instead of the Spin interpreter. :-)

    I like it! P1v if nothing else I suppose. Would this allow more than 64 instructions in fcache?
    Probably not because the CMM interpreter would still take up the same amount of COG memory. It just wouldn't consume any hub memory.

    Oh... right. Bummer :/
    The only real advantage you gain in using the Spin VM or putting the CMM VM in ROM is the 2K of hub memory that is used to store the CMM VM image before it is loaded into a COG. Unless you *really* need that 2K of memory, there is no real advantage.

  • Mike GreenMike Green Posts: 23,101
    Another reason to not put any interpreters in the P2 ROM is that it's masked ROM, not flash memory. Once it's set up in the chip design, it's there for good ... bugs and all. The ROM for the P2 will be fairly minimal ... enough native code to initialize the chip, assist in debugging, and load a program from a couple of different sources like SPI flash, a serial port, maybe EEPROM and maybe SD card.
  • David BetzDavid Betz Posts: 14,511
    Mike Green wrote: »
    Another reason to not put any interpreters in the P2 ROM is that it's masked ROM, not flash memory. Once it's set up in the chip design, it's there for good ... bugs and all. The ROM for the P2 will be fairly minimal ... enough native code to initialize the chip, assist in debugging, and load a program from a couple of different sources like SPI flash, a serial port, maybe EEPROM and maybe SD card.
    My suggestion was for P1 not P2 but it wasn't really serious anyway. As I mentioned, it only saves 2K of hub memory and locks you into that particular VM. I think the decision made to leave the interpreter out of the P2 ROM is a good one.

  • ersmithersmith Posts: 5,909
    DavidZemon wrote: »
    David Betz wrote: »
    DavidZemon wrote: »
    In LMM modes (lmm and all xmm*), it generates native assembly. In CMM, it generates custom 8-bit instructions that are then interpreted in a similar fashion to Spin (this means smaller code size for large projects, but larger code size for small projects because of the interpreter overhead)
    Actually, the overhead for LMM, XMM, and CMM are about the same. They all make use of a COG running a "kernel". In the case of CMM, the kernel interprets the bytecodes of the CMM virtual machine but it doesn't take up more space in doing that. However, all of the C kernels take up more space than Spin since its interpreter is in the Propeller ROM and doesn't take up any hub memory. Later versions of PropGCC attempt to recover the space for the kernel by adding it to the heap after loading it into a COG but that space is not available for more program code, only dynamically allocated data.

    Wow! I didn't realize the LMM kernel was so large. A very basic LMM kernel can be implemented with just four instructions right? read from PC -> execute -> increment PC -> loop
    What features is the above 4-instruction kernel missing that take up so much more memory?

    Jump and call (ways to modify the PC). Utility routines such as multiply, divide, count leading zeros. Useful constants like 0x0000FFFF. Fcache management functions. Not to mention that the PropGCC LMM kernel loop is unrolled so that we can execute 8 instructions before having to take the jump.

    Overall I think the PropGCC LMM kernel is a bit over 1K in size, with the rest of COG memory available for FCACHE and user routines. The CMM and XMM kernels are much bigger, close to 2K each.

    As David has mentioned, recent PropGCC releases overlay the LMM/CMM/XMM kernel with the BSS (uninitialized variable) and heap space, so the memory hit is minimal for most programs.

    Eric
Sign In or Register to comment.