Can't Wait for PropGCC on the P2?

11819202123

Comments

  • Also if I comment out the code on line 32 it runs but of course no data as that is the line I need to get the data. The object ping.spin2 is in the same file as the testing program.
    “Light thinks it travels faster than anything but it is wrong. No matter how fast light travels, it finds the darkness has always got there first, and is waiting for it.”
  • pilot0315 wrote: »
    Would someone please tell me why I get this error. I am attempting to port over the simple ping demo from spin to spin2 and I get the following error:

    "C:/Users/mm/Desktop/spin2gui 1.3.5/spin2gui/spin2gui/bin/fastspin" -2 -l -O1 -L "./lib" "C:/Users/mm/Desktop/spin2works/ping test .spin2"
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
    Version 3.9.16 Compiled on: Jan 29 2019
    child killed: segmentation violation
    $ fastspin -2 ping.spin2
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
    Version 3.9.18-beta- Compiled on: Feb  8 2019
    ping.spin2
    error: Symbol waitpne is of a type not handled by PASM output yet
    Segmentation fault: 11
    

    The error "error: Symbol waitpne is of a type not handled by PASM output yet" is coming from ping.spin2... Looks like a fastspin problem, not handling waitpne yet??

    The Segmentation Fault: 11 is possibly a side-effect of that error, but probably needs a look at as well.

    dgately
    Livermore, CA (50 miles SE of San Francisco)
  • You've found a bug in fastspin's error handling -- instead of crashing it should be complaining that waitpne is not defined. The waitpne function is not provided for P2.
  • There is no waitpne or waitpeq in P2ASM.

    I'd prefer it if the high level P2 languages would use those names and generate the equivalent P2ASM code. But I'm not sure what the authors of those languages want.

    Tom
  • Cool I found a "bug"! Well I will have to figure out another way to get this to work. Thanks
    “Light thinks it travels faster than anything but it is wrong. No matter how fast light travels, it finds the darkness has always got there first, and is waiting for it.”
  • It's tricky to reproduce that instruction exactly:

    There is a more complicated equivalent but there is two caveats that come with it. One is it consumes a specific shared hardware resource - an event compare register. The other is that all WAITxxx instructions block interrupts. Neither caveat may be of concern but the compiler isn't going to easily know if they are.

    The alternative approach is do a tight two instruction loop testing the specified pin with TESTP instruction. This eliminates both above potential concerns and is very easy to understand but introduces a tiny amount of jitter that wouldn't have been present in the original prop1 code.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • Thanks I will look into that.
    “Light thinks it travels faster than anything but it is wrong. No matter how fast light travels, it finds the darkness has always got there first, and is waiting for it.”
  • Dave Hein,
    I ran the batch file for p2gcc what is supposed to happen. I did not see anything. Is there something else I need to do go get it to run??
    Thanks
    Martin
    “Light thinks it travels faster than anything but it is wrong. No matter how fast light travels, it finds the darkness has always got there first, and is waiting for it.”
  • I'm not sure how you ran it, but I guessing you double-clicked on the p2gcc.bat file. If that's what you did you will see a momentary flash, where the window starts up and then immediately closes. What you need to do is run a "Command Prompt" window. If you have an icon for that, then click on that. Otherwise, you will need to go the start menu, which is the small Windows icon on the lower left of your screen. On Windows 10 it is under "Windows System". On Windows 7 it may be located somewhere else, such as in "Windows Accessories".

    Once you've opened a command prompt window use the cd command to change to the p2gcc directory. Within that directory type p2gcc, and it will list the options that you can use. You will need to add the bin directory to your path and define a P2GCC_LIBDIR environment variable that points to your lib directory. On my system I issue the two following commands:

    set PATH=%PATH%;C:\Users\Dave\Desktop\p2gcc\bin
    set P2GCC_LIBDIR=C:\Users\Dave\Desktop\p2gcc\lib

    After you do this you can build and load C programs. You can run the hello program by typing

    p2gcc -r -t hello.c

    There are a few other sample programs in the p2gcc directory.
  • I have a question about the prefix.spin2 code.

    In it I see this compiled code:
    00180 060          prefix_setup
    00180 060 f600ee08         mov     save_r0, r0
    00184 061 f600f009         mov     save_r1, r1
    00188 062 f20ff000         cmp     ptra, #0 wz     ' Check if ptra is zero
    0018c 063 ad900018  if_z   jmp     #prefix_setup1  ' If zero set sp to init_stack_ptr
    00190 064 f6002ff8         mov     sp, ptra
    

    shouldn't
    00188 062 f20ff000         cmp     ptra, #0 wz compile to f20e0000
    
    and
    00190 064 f6002ff8         mov     sp, ptra compile to f6005f00?
    

    Mike
  • For most instructions ptra is a register with an address of $1f8. For instructions, such as rdlong, wrbyte and others that access memory ptra is a memory pointer, and in that case it uses the pointer encoding.
  • iseriesiseries Posts: 379
    edited 2019-02-11 - 17:22:52
    So does F6002FF8 do the same as F6005F00?

    Mike

    Never mind. I figured it out. MOV SP, [PTRA].
  • Dave I will look at that. Yes you are correct I clicked on the p2gcc.bat file.
    “Light thinks it travels faster than anything but it is wrong. No matter how fast light travels, it finds the darkness has always got there first, and is waiting for it.”
  • I wish to tell all I am not a grand programmer as most of you are.

    So please excuse me.

    I am wanting to looking for the C programs can I get a fullduplexserial in C so I can get incoming asynchronous data. For my project in the p2
    thanks.

    btw I am an old coder from the fortran days. Old FORTRAN
    “Light thinks it travels faster than anything but it is wrong. No matter how fast light travels, it finds the darkness has always got there first, and is waiting for it.”
  • s. Btw there is a store in the san fernando valley that has mainframes if you are interested and tape drives of the old days

    let me know.
    nice toys to interface with

    “Light thinks it travels faster than anything but it is wrong. No matter how fast light travels, it finds the darkness has always got there first, and is waiting for it.”
  • pilot0315 wrote: »
    I wish to tell all I am not a grand programmer as most of you are.

    So please excuse me.

    I am wanting to looking for the C programs can I get a fullduplexserial in C so I can get incoming asynchronous data. For my project in the p2
    thanks.

    btw I am an old coder from the fortran days. Old FORTRAN

    Wat four ;)
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • pilot0315 wrote: »
    I am wanting to looking for the C programs can I get a fullduplexserial in C so I can get incoming asynchronous data. For my project in the p2
    thanks.

    It's easy to do telemetry inline. The hardware is at your disposal. Are you sure you need it as background?
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • pilot0315 wrote: »
    I am wanting to looking for the C programs can I get a fullduplexserial in C so I can get incoming asynchronous data. For my project in the p2
    thanks.
    The serial routines in the p2gcc library transmit and receive serial data only when they are called, so I don't think they will serve your purpose. However, I do have some code that runs in a separate cog that will receive serial data and buffer while the main code is running in cog 0, which may work for you. You can use the kbhit() function to determine if a character has been received, and then call getch() to receive the character. You first have to start the rx serial cog by calling start_rx_cog(). Use putch() to send characters without any processing. If you use putchar() it will convert linefeeds into carriage-return followed by a linefeed.

    c
    c
    3K
  • Dave,
    Thanks for the assist. I am having a hard time finding the directory. It has been ages since I have delt with dos files.
    “Light thinks it travels faster than anything but it is wrong. No matter how fast light travels, it finds the darkness has always got there first, and is waiting for it.”
  • Question?
    I have been attempting to start CogSerial.spin2 in a second cog and get this error. Wanting to use the serial program in two different cogs simultaneously. Was able to do it in P1 but seem not to be able to do it easily in P2.
    1139 x 699 - 116K
    “Light thinks it travels faster than anything but it is wrong. No matter how fast light travels, it finds the darkness has always got there first, and is waiting for it.”
  • @pilot0315, you're posting in the wrong thread again. You would have better luck getting help in one of the spin2gui or fastspin threads.
  • Dave: Where are you getting your library code from? If I'm going to try to contribute I'd like to use the same source. I've been looking at Eric's proplib repository that contains the code used in PropGCC.
  • Up to now I've been writing my own library functions. At some point I plan on porting the P1 PropGCC library code. So you could either write them from scratch, or you might want to copy them over from PropGCC. The PropGCC setjmp and longjmp may have tentacles in system code, so it might be better to do them from scratch. They just need to tie into the jmp_buf struct.
  • Dave Hein wrote: »
    Up to now I've been writing my own library functions. At some point I plan on porting the P1 PropGCC library code. So you could either write them from scratch, or you might want to copy them over from PropGCC. The PropGCC setjmp and longjmp may have tentacles in system code, so it might be better to do them from scratch. They just need to tie into the jmp_buf struct.
    I think the P1 setjmp/longjmp should work for your P2 compiler if you use the same calling conventions. It just saves and restores registers. They are written in assembler but they mostly just do wrlong and rdlong to save and restore the registers.
  • I think overall it makes sense for us to port the P1 PropGCC library over to P2. With appropriate #ifdefs I think we can make it work for both p2gcc and fastspin, and I think that would be worthwhile. I've started work on this for fastspin, but I haven't had time to try it out with p2gcc yet.

    The one place where I don't like the PropGCC library is the way it handles fopen() and FILEs. We introduced what I think in retrospect was a complicated driver mechanism so that the user could always use fopen("driver:somestring", "mode") to open a file. That's fine if there's an existing driver, but writing the device driver is another hoop to jump through. I think that was a mistake. I'd be inclined to save fopen("file", "r") and the like for accessing the SD card, and provide a new fopen_device function that looks something like:
      fopen_device(putc_func, getc_func, mode)
    
    Then you can quickly hook up any device you have a putchar and getchar for to the C library.

    Thoughts?
  • David BetzDavid Betz Posts: 13,288
    edited 2019-02-18 - 01:10:09
    ersmith wrote: »
    I think overall it makes sense for us to port the P1 PropGCC library over to P2. With appropriate #ifdefs I think we can make it work for both p2gcc and fastspin, and I think that would be worthwhile. I've started work on this for fastspin, but I haven't had time to try it out with p2gcc yet.

    The one place where I don't like the PropGCC library is the way it handles fopen() and FILEs. We introduced what I think in retrospect was a complicated driver mechanism so that the user could always use fopen("driver:somestring", "mode") to open a file. That's fine if there's an existing driver, but writing the device driver is another hoop to jump through. I think that was a mistake. I'd be inclined to save fopen("file", "r") and the like for accessing the SD card, and provide a new fopen_device function that looks something like:
      fopen_device(putc_func, getc_func, mode)
    
    Then you can quickly hook up any device you have a putchar and getchar for to the C library.

    Thoughts?
    Will we even have a standard interface to drivers on P2? I remember trying to define one for P1 and we could never get consensus.

    Anyway, I think getting your proplib to work for both fastspin and p2gcc would be a good idea. I'm in the process of moving a couple of functions over so I can compile ebasic3 under p2gcc. I guess I could just keep going to see how far I can get. That is, unless one or both of you are already doing this.
  • David Betz wrote: »
    ersmith wrote: »
    I'd be inclined to save fopen("file", "r") and the like for accessing the SD card, and provide a new fopen_device function that looks something like:
      fopen_device(putc_func, getc_func, mode)
    
    Then you can quickly hook up any device you have a putchar and getchar for to the C library.

    Thoughts?
    Will we even have a standard interface to drives on P2? I remember trying to define one for P1 and we could never get consensus.

    Anyway, I think getting your proplib to work for both fastspin and p2gcc would be a good idea. I'm in the process of moving a couple of functions over so I can compile ebasic3 under p2gcc. I guess I could just keep going to see how far I can get. That is, unless one or both of you are already doing this.

    The more people who can work on this stuff the better. And the more we can share across projects the better too. So thanks for helping out!

  • ersmith wrote: »
    The more people who can work on this stuff the better. And the more we can share across projects the better too. So thanks for helping out!
    Okay, so what's the best way to do this? Maybe I should make a proplib2 project in GitHub and start populating it from your proplib project for P1? I guess another question should be whether this new library should target P1 as well as fastspin and p2gcc?
  • I think it would be good to use the library source for both P1 and P2. As far as the file system, the P1 system seem to work OK. However, it would be good to look at other methods.
  • Eric: Do you intend to keep using the _IMPL method of associating function prototypes with the files containing their implementation? If so, I will have to add those clauses to all of the header files I move over from proplib. You've already done that for the ones you've moved over.

    I mean lines like this from string.h:
        char * strchr(const char *, int) _IMPL("libc/string/strchr.c");
    
Sign In or Register to comment.