Shop OBEX P1 Docs P2 Docs Learn Events
compiling ebasic3 with p2gcc — Parallax Forums

compiling ebasic3 with p2gcc

David BetzDavid Betz Posts: 14,516
in Propeller 2
I just tried compiling my ebasic3 interpreter using p2gcc and I realize that I don't know how to invoke it properly. Here is the command I issued and the error message I got. I see it has a -L option to specify the library base address but how do I tell it how to locate prefix.spin2? 
p2gcc -o eb3_p2gcc -D PROPELLER -L ../p2gcc/lib ebasic.c db_compiler.c db_edit.c db_expr.c db_generate.c db_image.c db_scan.c db_statement.c db_symbols.c db_system.c db_vmdebug.c db_vmint.c editbuf.c  simple_vsnprintf.c osint_prop2.c
Could not open /prefix.spin2
«1

Comments

  • Dave HeinDave Hein Posts: 6,347
    You have to define the environment variable P2GCC_LIBDIR. I normally go into the p2gcc/lib directory and then type: 
    export P2GCC_LIBDIR=$PWD
  • David BetzDavid Betz Posts: 14,516
    Dave Hein wrote: »
    You have to define the environment variable P2GCC_LIBDIR. I normally go into the p2gcc/lib directory and then type: 
    export P2GCC_LIBDIR=$PWD
    Thanks! I did that and removed the -L option from my command line but now I get this: 
    p2gcc -o eb3_p2gcc -D PROPELLER ebasic.c db_compiler.c db_edit.c db_expr.c db_generate.c db_image.c db_scan.c db_statement.c db_symbols.c db_system.c db_vmdebug.c db_vmint.c editbuf.c  simple_vsnprintf.c osint_prop2.c
Couldn't open prefix.o

  • Dave HeinDave Hein Posts: 6,347
    You have to build the library. Go into p2gcc/lib and type ./buildlibs.
  • David BetzDavid Betz Posts: 14,516
    edited 2019-02-17 23:09
    Dave Hein wrote: »
    You have to build the library. Go into p2gcc/lib and type ./buildlibs.
    Thanks! I now get this. I guess I'd better help flesh out the library! :smile:
    _setjmp is unresolved
_strchr is unresolved
_longjmp is unresolved
_strtoul is unresolved
_vsnprintf is unresolved
_memmove is unresolved

  • roglohrogloh Posts: 5,787
    @"Dave Hein" , Would it make sense to have the library building also done in the top level build_* file(s) for the different platforms? I found I needed to do that step too through some trial and error before I could build the demos and I don't think that part was explained in the readme file.
  • Dave HeinDave Hein Posts: 6,347
    @rogloh, yes it does make sense to include that in the top level build scripts. I'll go ahead and add it.

    @David, adding strchr, strtoul and memmove should be fairly easy. There is an existing vsprintf, so it shouldn't be to hard to add vsnprintf. I think for setjmp and longjmp I just need to store the values of lr and sp. I need to look into this to make sure that's sufficient. Feel free to implement the functions, and I'll add them to the repository.
  • David BetzDavid Betz Posts: 14,516
    I moved strchr, strtoul, and memmove over from the PropGCC library and started using vsprintf instead of vsnprintf. I also created a dummy setjmp/longjmp as below and was able to get ebasic3 to build using p2gcc but it doesn't seem to run. It doesn't even print out its banner at the start. I've attached my sources. 
    #include <setjmp.h>

void longjmp(jmp_buf env, int val)
{
}

int setjmp(jmp_buf env)
{
    return 0;
}
    zip
    zip
    ebasic3.zip
    40K
  • Dave HeinDave Hein Posts: 6,347
    I added a sleep(1) at the beginning of the main function, and it does print "ebasic3". I then added a few trace prints in main, and it appears to step through main, and then returns at the end.

    p2gcc did have a problem with initialized char and short variables that are declared outside of functions. If the total size of the chars and shorts isn't a multiple of 4 it creates an odd size object. When this is linked with the other objects it causes them to not be long-aligned. I modified p2link to check for this, and it pads out odd size objects when linking. I checked this fix for p2link_src/p2link.c into GitHub.
  • David BetzDavid Betz Posts: 14,516
    Dave Hein wrote: »
    I added a sleep(1) at the beginning of the main function, and it does print "ebasic3". I then added a few trace prints in main, and it appears to step through main, and then returns at the end.
    Ah, I keep forgetting to add a delay at the start before printing anything. Thanks!
    p2gcc did have a problem with initialized char and short variables that are declared outside of functions. If the total size of the chars and shorts isn't a multiple of 4 it creates an odd size object. When this is linked with the other objects it causes them to not be long-aligned. I modified p2link to check for this, and it pads out odd size objects when linking. I checked this fix for p2link_src/p2link.c into GitHub.
    Thanks but are you saying that the GitHub sources aren't necessarily the most current code? Where do I go to make sure I'm using the latest version?
  • Dave HeinDave Hein Posts: 6,347
    GitHub contains the most up-to-date code. I had committed the changes into GitHub just before I made my last post.
  • David BetzDavid Betz Posts: 14,516
    Dave Hein wrote: »
    GitHub contains the most up-to-date code. I had committed the changes into GitHub just before I made my last post.
    Thanks! Just wanted to make sure I was always working with the most recent code. I update from GitHub frequently so I guess that should take care of it. Thanks for all of your work on this!
  • Dave HeinDave Hein Posts: 6,347
    I added strchr, strtoul, memmove, setjmp and longjmp to the p2gcc library.
  • David BetzDavid Betz Posts: 14,516
    Dave Hein wrote: »
    I added strchr, strtoul, memmove, setjmp and longjmp to the p2gcc library.
    Thanks!

  • David BetzDavid Betz Posts: 14,516
    David Betz wrote: »
    Dave Hein wrote: »
    I added strchr, strtoul, memmove, setjmp and longjmp to the p2gcc library.
    Thanks!
    I just got home and tried compiling ebasic3 with your new compiler. I'm definitely getting closer. It compiled and linked without errors and the line editor seems to work but the bytecode compiler or interpreter are having some problems. I'm also still missing setjmp/longjmp. Here is the output of my first test run: 
    Davids-Mac-mini:ebasic3 dbetz$ load eb_p2gcc
Unsupported baudrate 921600. Use Setting clock_mode to 12427f8
Loading eb_p2gcc - 75964 bytes
eb_p2gcc loaded
( Entering terminal mode.  Press Ctrl-] to exit. )
ebasic3
list
OK
10 print "Hello, world!"
20 for x = 1 to 10
30 print x, x*x
40 next x
list
10  print "Hello, world!"
20  for x = 1 to 10
30  print x, x*x
40  next x
OK
run
Hello, world!
0	1222103644
-167504895	1555899120
-60809720	-136850852
-167764472	-1689447968
-251391696	659245778
-83878385	218027164
-83878898	1999267432
1919055219	-482590542
OK
  • Dave HeinDave Hein Posts: 6,347
    setjmp/longjmp should be in the library. I assume you ran build_macos after getting a fresh copy of p2gcc from GitHub. This script now run the buildlibs script. You should have a setjmp.o file in the lib directory. Can you run p2dumpobj, and see if setjmp appears in the output?

    When I build and run the code you posted in the zip file it just prints ebasic3. I added a print before the "return 0" in main, it just appears to run straight through main, and then returns. Did you have to make any changes to get it to the point where you could edit? Do I need to put something in argc and argv? They are initialized to zero.
  • David BetzDavid Betz Posts: 14,516
    Sorry. I still had my dummy setjmp.c in place. I removed it and rebuilt using your version. Things still don't work but I think the problem is mine at this point because they don't work on the Mac either. I typed the line "print a[" which should have displayed an error. It did that but then failed to restart the editor. BTW, the latest code is now in:

    https://github.com/dbetz/ebasic3

    You can build the p2gcc version with this command:
    make eb_p2gcc


  • David BetzDavid Betz Posts: 14,516
    edited 2019-02-20 02:32
    Okay, I just pushed a fix to the error handling bug. Errors now return to the editor command processor. BASIC programs still don't compile correctly to byte code under p2gcc even though they do on the Mac. I still have to track down why.

    Edit: And thanks for the setjmp/longjmp implementation. It seems to work fine!
  • Dave HeinDave Hein Posts: 6,347
    edited 2019-02-20 02:40
    I was able to do a simple straight-line program, but things do go haywire if I add more than a few statements. This program works up to line 50 where it prints the wrong thing. 
    10 i=123
20 print i
30 j = 3
40 print j
50 print i j
  • David BetzDavid Betz Posts: 14,516
    Dave Hein wrote: »
    I was able to do a simple straight-line program, but things do go haywire if I add more than a few statements. This program works up to line 50 where it prints the wrong thing. 
    10 i=123
20 print i
30 j = 3
40 print j
50 print i j
    Something strange is happening with the byte code compiler. It seems to only emit every other instruction. It doesn't do that when compiled for the Mac. I have to track down what is going wrong.
  • David BetzDavid Betz Posts: 14,516
    Dave Hein wrote: »
    50 print i j
    FYI, that would have to be written: 
    50 print i, j
  • Cluso99Cluso99 Posts: 18,069
    I have a question...

    How hard would it be to have an option to use the inbuilt ROM Monitor Serial Routines? They are just hubexec calls and the requirement of COG $1E0-$1EF for variables. They have not changed in the new respin.
  • AJLAJL Posts: 517
    Cluso99 wrote: »
    I have a question...

    How hard would it be to have an option to use the inbuilt ROM Monitor Serial Routines? They are just hubexec calls and the requirement of COG $1E0-$1EF for variables. They have not changed in the new respin.

    That sounds much harder than everyone doing their own variation on bit-bashing serial. It'll never catch on ;)
  • David BetzDavid Betz Posts: 14,516
    Cluso99 wrote: »
    I have a question...

    How hard would it be to have an option to use the inbuilt ROM Monitor Serial Routines? They are just hubexec calls and the requirement of COG $1E0-$1EF for variables. They have not changed in the new respin.
    Do they use smart pins? It would be nice to have some character buffering on input.

  • Dave HeinDave Hein Posts: 6,347
    Cluso99 wrote: »
    I have a question...

    How hard would it be to have an option to use the inbuilt ROM Monitor Serial Routines? They are just hubexec calls and the requirement of COG $1E0-$1EF for variables. They have not changed in the new respin.
    I know there's a ROM Monitor document some where, but I can't find it. Where's the document located?
  • iseriesiseries Posts: 1,492
    So the getch.s and the putch.c could be changed to use the monitor code?

    Mike
  • Cluso99Cluso99 Posts: 18,069
    David Betz wrote: »
    Cluso99 wrote: »
    I have a question...

    How hard would it be to have an option to use the inbuilt ROM Monitor Serial Routines? They are just hubexec calls and the requirement of COG $1E0-$1EF for variables. They have not changed in the new respin.
    Do they use smart pins? It would be nice to have some character buffering on input.
    Yes, the smartpins are used. Fixed to P62 & P63 but could be patched. INT is not used.

    There are two reads, one is char only, no buffering, and the other reads a string terminated with <cr>.

    Don’t have the link just now. Will post it later.

    An extra feature i found handy is to output a formatted memory dump. Set registers with start address, end address, and call it. Can be cog/lut/hub and formats address, 16 hex byte pairs, 16 ascii chars per line, which BTW can be saved and later fed back into the monitor lo load memory.
  • Cluso99Cluso99 Posts: 18,069
    iseries wrote: »
    So the getch.s and the putch.c could be changed to use the monitor code?

    Mike


    They were my thoughts. Plus read/write strings, etc. BTW strings must be in hub.
  • David BetzDavid Betz Posts: 14,516
    Cluso99 wrote: »
    [Yes, the smartpins are used. Fixed to P62 & P63 but could be patched. INT is not used.

    There are two reads, one is char only, no buffering, and the other reads a string terminated with <cr>.
    Doesn't using the smartpin provide at least one character of buffering even in single character mode? Also, does your line input code support backspace for line editing?
  • Cluso99Cluso99 Posts: 18,069
    Yes and yes
  • David BetzDavid Betz Posts: 14,516
    Cluso99 wrote: »
    Yes and yes
    Thanks. I can try using one of these functions but Dave will have to decide if he wants his library to use them.

Sign In or Register to comment.