Shop OBEX P1 Docs P2 Docs Learn Events
expanding code space — Parallax Forums

expanding code space

frdchangfrdchang Posts: 14
edited 2004-12-09 00:05 in General Discussion
hello,

i don't think i will run into this problem, but i wish to address it now just in case,

if run out of code space, what are my options? (other than be more clever in programming)

i'm curious how the basic stamp works (how the interpretation works even though the code is not running of the external ram)

thanks,
fred

Comments

  • BeanBean Posts: 8,129
    edited 2004-12-07 12:09
    1) Optimize the existing code
    2) Put code in subroutines.
    3) If using SX/B convert some code to assembly.
    4) Use the SX48 or SX52 (if NOT using SX/B). (Has twice the code space)

    Bean.
  • allanlane5allanlane5 Posts: 3,815
    edited 2004-12-07 15:13
    Note the SX/B stuff does not work the way the BS2 does. The SX/B is a 'true' compiled language. Each SX/B keyword you use is translated into one or more native SX28 assembly instructions. There's no interpretation in this platform, no external EEPROM fetch cycle.
  • Paul BakerPaul Baker Posts: 6,351
    edited 2004-12-07 16:36
    A cannot answer this in full at this time, since I don't want to get in trouble with my IT dept. So I will prepare an answer off-line and run to Kinkos sometime soon to answer this if it hasn't already. In a nutshell, interpretive data stored externally can only refer to actual machine language routines stored in actual program space, which can be done faster with subroutining all common code. There is only a small niche where you need all program space for subroutines and need space for tokens refering to the subroutines where this method is most benificial. If you have lots and lots of unique code an interpreter approach will not work.

    Paul
  • frdchangfrdchang Posts: 14
    edited 2004-12-08 08:09
    hello,


    so basically the sx chip has onboad a set of native functions that reside in its codespace, and the eeprom just directs which function to call? (with some overhead master function juggliging in between the two?)
  • allanlane5allanlane5 Posts: 3,815
    edited 2004-12-08 15:48
    Hmm.

    The SX chip has, on-the-chip, a set of 'file registers' (same as SRAM) and a 'FLASH' memory space. The SX hardware is a set of registers that execute instructions from the SX instruction set.

    When you power up, the SX goes to location zero of the 'FLASH' memory space, reads the first instruction there, and executes it. It continues executing instructions from on-chip FLASH as long as power is applied. The "set of native functions" IS the SX assembly language. The "master function" is the cycling of the Program Counter.

    With the SX, you are "on-the-hardware". There IS NO 'executive program' running -- unless you yourself write it, and burn it into the SX Flash memory with the SX-Key hardware. This is assembly level programming at its least complicated.

    Now, when you write a program using the 3.0 IDE with SX/B, you can use some of the PBasic keywords. What the SX/B compiler does with those keywords is expand them into equivalent SX assembly, and put the expanded version into the FLASH.

    "frdchang" -- the scenario you describe matches the way the BS2 works. The BS2 has in its (Parallax Proprietary) internal FLASH rom the library of PBasic commands. When you download a program to the BS2, the BS2 puts a 'tokenized' version of your program in an EEPROM on the BS2 module. When you run a BS2 program, the BS2 'executive' in its FLASH rom reads the tokens from the EEPROM, then 'executes' the assembly routine equivalent from the PBasic Library in its FLASH rom.

    The SX does not do any of this. This means programming the SX is a little more involved than programming the BS2. The SX/B language is a MUCH easier way of programming the SX than writing your code in pure SX assembly. But the output of the SX/B IS 'pure' assembly.
  • Paul BakerPaul Baker Posts: 6,351
    edited 2004-12-08 16:32
    frdchang, you have correctly surmised the point I was trying to make. allanlane5 has covered the points I was going to explain more fully. -Paul
  • Guenther DaubachGuenther Daubach Posts: 1,321
    edited 2004-12-08 18:26
    allanlane5,

    your explanation is a nice description how the SX works with one little bug:

    When the SX is powered up, it does not read the first instruction at location zero of the FLASH memory. Actually, it reads the topmost location of the FLASH memory where it expects a jump instruction directing it to the entry point of the main program code. In an assembly program, the RESET directive is used to specify the "jmp to main entry" instruction in the topmost FLASH location.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Greetings from Germany,


    G
  • allanlane5allanlane5 Posts: 3,815
    edited 2004-12-08 18:43
    AHA! So that's why the ISR (Interrupt Service Handler) is always at location 0, and why each SX program starts with a "reset start" command.

    Thanks Guenther! I learn something new every day.
  • BeanBean Posts: 8,129
    edited 2004-12-08 20:01
    I found this out the hard way, when I tried to run some data all way to $7FF.
    Took a little while to figure out what was wrong.

    Bean.
  • Guenther DaubachGuenther Daubach Posts: 1,321
    edited 2004-12-09 00:05
    allanlane5 said...
    AHA! So that's why the ISR (Interrupt Service Handler) is always at location 0, and why each SX program starts with a "reset start" command.

    Thanks Guenther! I learn something new every day.
    Yes,

    the entry address for the ISR (not IRS - in Germany, the IRS is called "Finanzamt", and I don't like it too much) is hard-coded in the SXes, i.e. when an interrupt event occurs, program execution always branches to address $000 in·program memory. Therefore, it is a good idea to place a RETI instruction at that address when·you don't want to handle interrupts in your code. It is just there to make sure that the SX "behaves well" in case an interrupt is entered unexpectedly.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Greetings from Germany,


    Günther
Sign In or Register to comment.