Help using pPropellerSim

Comments

• nyholku Posts: 14

  2020-02-01 10:42

  More results from experimentation.
  
  There are one or two small bugs in the pPropellerSim which are show stoppers if one is not aware of them.
  
  1. The Cold Reset menu command is not implemented
  2. hwreset() function in the Java code does not call cog.reset(true) so after first run of any spin/pasm code
  
  Together these means that is next to impossible to try to run some code and one is totally confused.
  
  After fixing those I'm able to run a simple spin program that launches a simple .pasm into a separate COG like this:
  

  pub main
        cognew (@loop,0)
  dat
  	   org	0
  huuhaa long $deadbeef
  loop
        add huuhaa,#1
        
        jmp #loop
  

  
  However I'm unable to get the almost equally simple C/pasm combo to produce anything in cog 1, cog 0 just spins (no pun intended) in tight loop (maybe pulling something from hub memory and executing it?).
  
  How is the C code supposed to start executing?
  
  After reset Propeller loads the spin interpreter to COG 0 which then starts to read and execute SPIN code from hub, so is there some sort of SPIN launcher code to launch the 'kernel' mentioned in propellergcc docs ?
  
  Is this documented somewhere?
  
  I even wrote the simplest of C programs but simulating it does not produce anything that makes sense:

  #include "simpletools.h"                      
  int main()                                    
  {
    int cnt=0;
    while(1)
    { 
    OUTA=cnt;
    cnt++;
    }  
  }
  
• Wuerfel_21 Posts: 4,448

  2020-02-01 11:31

  Hmm, have you tried the GEAR emulator? That one sorta worked last time I checked (albeit at some 1% of real speed) and includes bytecode-level spin debugging.
  
  Anyways, emulating the Prop is a bit of a lost cause, it's just kinda too fast, yet reliant on precise timing to get anywhere near 100% real speed. I do most of my debugging on a real chip, printing out values on the serial port.
• nyholku Posts: 14

  2020-02-01 12:25

  @Wuerfel_21
  
  Yeah, tried GEAR. That too works with simple spin/pasm but not with the C-code.
  
  Hard to debug when there is so little info on how the C starts executing and what is and how the kernel that pulls code from the hub memory to cog for execution works.
  
  The Gear speed is pitiful, after all 20 MPIS/cog is not that fast when I'm running my stuff on 2.6 GHz 8 core i7. PIC gpsim runs at equivalent of 20 MHz which translated to 5 MIPS. I think the problem with Gear is just the screen update, there is no point and need to update the screen so often.
  
  Also Gears seems to be Windows only at least out of the box.
  
  I kind of agree with simulation point in general, but still it would be convenient to have good reliable emulator.
  
  I mainly picked pPropellerSim cause it is Java based and I'm very proficient with all things Java AND it is so much more cross platform than any of the other alternatives. I was able to get the project compile in minutes and debug those above mentioned problems in less than half an hour.
  
  Projects like this (writing a simulator) are very tempting but I try to steer away from them as this can easily turn into making tools to make tools for a side project of a side project.
  
  Oh well, I'll give this a rest for a day or two and see if someone has some helpful input.
  
  cheers Kusti
  
  
• Wuerfel_21 Posts: 4,448

  2020-02-01 18:12 edited 2020-02-01 18:14

  Well, to be honest, "I do most of my debugging on a real chip" was a lie. I actually wrote a very project-specific high-level emulator that I use for working on my prop game (altough only to reduce the amount of times I have to swap the SD card around - too lazy to write a proper debugger). The high-level program is written with a custom assembler that can also emit C++ code that I then link with C++ re-implementations of all the low-level driver code - this kind of approach is really fast, but requires a lot of extra effort (since this kind of high-level emulator will inevitably have a different set of quirks than real HW (and obviously someone has to write the C++ driver replacements)). In my case that's fine, in the end I want a PC version, anyways.
  
  If you're writing high-level code in C, I guess it's easier, since you can just compile it with x86 GCC instead of having to roll custom tooling Of course, a more.. kinetic? (involving motors,sensors,etc...) project wouldn't really work on a PC. (Unless hooked up to some kind of physics simulator?)
  
  On the topic of pPropellerSim, I assume you have version 1.0.0.12?
  Looking at the org.pacito.propeller.Cog class, many of the instructions are implemented very incorrectly. (for example, the Z flag result from MIN/MAX is supposed to be "S==0", not "S==D". The Z flag result from MOVS/MOVD/MOVI is also incorrect. I don't see where the flag outputs for hubram load/store are handled.). In case you want to try fixing it and want to take the fast path, I've attached some relevant source from my above-mentioned bespoke assembler / high-level emulator. It doesn't have every instruction (anything I/O or timing-related is not present) and some pseudo-ops specific to my XMM/LMM kernal, but all the ALU ops are there and as far as I can tell, correct (I've fuzzed each instruction - identical results on real HW). The interesting bits are the ALUINSTRUCTIONS table and the _frame_c method.
  (Stupid forum doesn't like .rb files, so once again, a ZIP)

  zip

  zip

  rasm_instructions.zip

  4K

  rasm_instructions.zip 4.4K
• yeti Posts: 818

  2020-02-01 22:55

  Does simpletools somehow preset DIRA?
  
  I currently have no PropGCC at hand but trying something remotely related with FastSpin yields the expected output.

  

  

  20200201-225212-GMT__OUTA_CNT.png

  1600 x 900 - 152K

  20200201-225212-GMT__OUTA_CNT.png 152.2K