An interesting point of reference is that xbasic compiled with Catalina C creates a binary of about 520k. The exact same code compiled for ZOG generates a 67k binary. Of course, I would expect that the Catalina C code would run much faster.
I thought Zog and Catalina binaries were of comparable sizes. In fact when we first started comparing Catalina was smaller as Ross has a hand made smaller C library for the printf and stdio stuff (Are you using that?). Whereas the standard printf and friends that comes with zpugcc/newlib were quite large.
As for speed, that's a puzzle until something is actually run. I would expect that if Catalina compiles to bigger code then it would slug it somewhat when running from external RAM as more code has to be fetched. But then Catalina has a faster virtual machine (dare I day that?).
Anyway, sounds like we can soon fill up that 32MB Gadget Gangster SDRAM with code
xbasic is about 4000 lines of code. I didn't use optimization in either build so maybe that would change the results. I used -lci with Catalina and the standard newlib runtime library with ZOG.
Edit: I've attached the source code for xbasic along with the makefiles I use to build it for Catalina C and ZOG.
I just updated this post with the sources for xbasic in case anyone wants to try to determine why the Catalina binary file is so much larger than the ZOG one.
Something is wrong with your compile. I just downloaded your sources and compiled them and got a total binary file of 117k without using the optimizer (109k with the optimizer).
The size of the code segment is 65k.
I had to change one line in your makefile.cat, since your original wasn't compiling the program to use XMM:
LDFLAGS=-x5 -M256k -y
Can you try the compile again with this change?
Ross.
P.S. I tried to run it on a DRACBLADE - it gets past VM_sysinit(), but does not complete the InitCompiler() function. You'll probably be quicker at debugging it than me.
Wow! If it only takes 65k of code that would be great! I'm not surprised that it didn't run. I only built it to see how big the binary was going to be. I never actually tried loading it into a Propeller board. I was planning on using it on the C3 once your flash version is available. I guess I could try the Dracblade now that I know it isn't going to completely fill the 512k of memory. I'm not sure why my .binary file was so big. I'll try again with your options.
As you suspected, recompiling with those options gave me a smaller binary. In my case it was 119k without optimization. Not sure why it's different from what you got but at least it's in the same ballpark. I'll try building for Dracblade and debugging it later tonight. I need to read over the manual to find out how to setup standard input/output correctly. That's probably why it isn't working now. I think I'm just using getc/putc and/or getchar/putchar and expecting the runtime library to handle everything else. Will I be able to use fopen/fclose/etc to do file I/O?
I recompiled it using the XMM SMALL memory model (-x2) and I can now get as far as entering lines in the editor (note that you have to press CTRL-J instead of RETURN). But I can't list the lines properly, and the program crashes when try and I run it.
One thing - there seems to be a problem on the DRACBLADE in the XMM LARGE memory model (-x5) - which is the one you will ultimately need to use. Until I track this down, stick to the XMM SMALL model, and just note you will be severely memory constrained as all the data and the stack must fit into 32k, along with all the VGA buffers etc.
You will be able to use fopen/fclose etc - but you have to compile with the "extended" library - i.e. use -lcx or -lcix. This will make your binary slightly larger.
If you're looking at the actual file size in bytes, you're probably seeing a file size of 119,940 - this is what I mean by 117k (i.e. 119,940/1024). You actual file size may vary by a couple of bytes as I am using a different target and XMM kernel (one which I haven't released yet).
BTW - when compiled with -x2 and -lcix I get a file size of 138,284 (=135k) - i.e. adding file access to stdio adds about 18k.
I recompiled it using the XMM SMALL memory model (-x2) and I can now get as far as entering lines in the editor (note that you have to press CTRL-J instead of RETURN). But I can't list the lines properly, and the program crashes when try and I run it.
It's possible that this is a bug in xbasic not a problem with the port to Catalina. I wrote xbasic (then called xgsbasic) for PIC and AVR microcontrollers and I used 16 bit integers. I recently updated it to use 32 bit integers for the Propeller and there may be bugs lingering from that conversion since I haven't done much testing yet. My standard test program is this:
10 for x=1 to 10
20 printf("%d %d\n", x, x*x)
30 next x
Yeah, I know printf doesn't seem like it belongs in Basic but that's the way it works at the moment. Once I get this 32 bit version working reliably I'm going to add dynamic string support back in and some means of interfacing with Propeller code. At least access to some of the registers like CNT, DIRA, OUTA, INA, etc.
I won't get time to do any more on this today. Today is my day for (hopefully) finishing off the Flash loader for the C3. After that I'll go back and figure out what's wrong with the XMM LARGE model on the DRACBLADE - that one's a bit odd, since I have successfully run much larger problems than this on that platform. I'm just a bit worried that I may have broken something in the 2.9 release.
After that if you're still having problems I can give you a hand with xbasic.
Why are you assuming that xbasic not running is a problem with the XMM large model on the Dracblade? It seems to me that it's more likely to be my bug. The xbasic source is kind of a mess because I hacked it to try to get it to run on the Propeller. Originally the bytecode compiler ran on a PC and the VM ran on the target microcontroller. My attempts to squeeze it into the small memory space on the AVR and PIC may be the source of the problems. I'm going to try to cleanup the source code before I assume there is anything wrong with your runtime environment.
Why are you assuming that xbasic not running is a problem with the XMM large model on the Dracblade? It seems to me that it's more likely to be my bug. The xbasic source is kind of a mess because I hacked it to try to get it to run on the Propeller. Originally the bytecode compiler ran on a PC and the VM ran on the target microcontroller. My attempts to squeeze it into the small memory space on the AVR and PIC may be the source of the problems. I'm going to try to cleanup the source code before I assume there is anything wrong with your runtime environment.
Hi David,
Could be either, I suppose - but I had problems running the debugger on this program, which seems to indicate that we may both have problems!
It's a very simple Basic interpreter. It compiles to bytecode and then interpreters the bytecodes. It's still under development though. It isn't really very useful in its current form. However, it does support functions and subroutines with named arguments. Also, it doesn't really use line numbers except in the editor.
I'm trying to load xbasic into my dracblade board and am having trouble. Any idea why I would get these errors?
C:\Users\dbetz\Dropbox\xbasic>payload -p 10 XMM bin\xbasic.binary
Using Propeller (version 1) on port COM10 for first upload
Using port COM10 for subsequent uploads
Warning: no sync received for addr 00000000
Warning: no sync received for addr 00000000
Warning: no sync received for addr 00000000
Warning: no sync received for addr 00000000
Warning: no sync received for addr 00000000
Error: too many retries for addr 00000000
I'm trying to load xbasic into my dracblade board and am having trouble. Any idea why I would get these errors?
C:\Users\dbetz\Dropbox\xbasic>payload -p 10 XMM bin\xbasic.binary
Using Propeller (version 1) on port COM10 for first upload
Using port COM10 for subsequent uploads
Warning: no sync received for addr 00000000
Warning: no sync received for addr 00000000
Warning: no sync received for addr 00000000
Warning: no sync received for addr 00000000
Warning: no sync received for addr 00000000
Error: too many retries for addr 00000000
Hi David,
Looks like the XMM.binary utility program is not working. Have you re-compiled it for the DRACBLADE?
Go to the utilities folder and type
build_all DRACBLADE
Then copy the XMM.binary to your local folder (you won't have to do this in the next release!).
Looks like the XMM.binary utility program is not working. Have you re-compiled it for the DRACBLADE?
Go to the utilities folder and type
build_all DRACBLADE
Then copy the XMM.binary to your local folder (you won't have to do this in the next release!).
Ross.
Funny you should mention that. Yes, I did run 'build_all dracblade' but I couldn't do it in the C:\Program Files\Catalina\utilities" directory because I guess I don't have write access to that directory. The odd thing is that the batch file ran with no errors but didn't write any output files. I had to run it from a different directory.
Ah, I think the problem was that I typed "dracblade" instead of "DRACBLADE". It's loading now but not working. All I get is a flashing underscore at the top of the screen. I guess I have some debugging to do. Thanks for your help.
Must be something wrong with my Dracblade board. I can't get it to work compiled with -x2 either. All I get is a green screen with a flashing cursor in the upper left. No xBasic banner or anything.
Banner? What banner? I didn't see anything either until I put a couple of printf() calls in - maybe there is something wrong with your output function?
Banner? What banner? I didn't see anything either until I put a couple of printf() calls in - maybe there is something wrong with your output function?
Ross.
This like from db_edit.c is supposed to print a banner. Ultimately, this ends up calling putchar() for each character .
Aha! I just looked at your VM_printf() function, and it uses streams - stream support requires the extended library. When I compile your program with -lcix I see the banner.
Just for good measure, I typed in your 3 line basic test program - and it ran!
Okay, now I get the xBasic banner but my PS2 keyboard doesn't seem to work. I've never tried the PS2 keyboard on this Dracblade board though so I may have missed a solder joint or something. I'll try to track that down tomorrow. Thanks for your help!
No worries. You could always compile your program with the PC HMI option (-D PC) and use a serial terminal emulator.
Ross.
Okay, I tried that and it's definitely faster than the ZOG version. I just wish I knew why the PS2 keyboard doesn't work. I looked at the solder joints and they look okay to me. Maybe I should try loading some simple Spin code to test it.
Comments
I think it is an lcc bug - the warning should not be issued in the case of the null pointer. You'll just have to ignore the warning.
Ross.
I thought Zog and Catalina binaries were of comparable sizes. In fact when we first started comparing Catalina was smaller as Ross has a hand made smaller C library for the printf and stdio stuff (Are you using that?). Whereas the standard printf and friends that comes with zpugcc/newlib were quite large.
As for speed, that's a puzzle until something is actually run. I would expect that if Catalina compiles to bigger code then it would slug it somewhat when running from external RAM as more code has to be fetched. But then Catalina has a faster virtual machine (dare I day that?).
Anyway, sounds like we can soon fill up that 32MB Gadget Gangster SDRAM with code
Edit: I've attached the source code for xbasic along with the makefiles I use to build it for Catalina C and ZOG.
Something is wrong with your compile. I just downloaded your sources and compiled them and got a total binary file of 117k without using the optimizer (109k with the optimizer).
The size of the code segment is 65k.
I had to change one line in your makefile.cat, since your original wasn't compiling the program to use XMM:
Can you try the compile again with this change?
Ross.
P.S. I tried to run it on a DRACBLADE - it gets past VM_sysinit(), but does not complete the InitCompiler() function. You'll probably be quicker at debugging it than me.
Thanks,
David
Some more info ...
I recompiled it using the XMM SMALL memory model (-x2) and I can now get as far as entering lines in the editor (note that you have to press CTRL-J instead of RETURN). But I can't list the lines properly, and the program crashes when try and I run it.
One thing - there seems to be a problem on the DRACBLADE in the XMM LARGE memory model (-x5) - which is the one you will ultimately need to use. Until I track this down, stick to the XMM SMALL model, and just note you will be severely memory constrained as all the data and the stack must fit into 32k, along with all the VGA buffers etc.
You will be able to use fopen/fclose etc - but you have to compile with the "extended" library - i.e. use -lcx or -lcix. This will make your binary slightly larger.
Ross.
If you're looking at the actual file size in bytes, you're probably seeing a file size of 119,940 - this is what I mean by 117k (i.e. 119,940/1024). You actual file size may vary by a couple of bytes as I am using a different target and XMM kernel (one which I haven't released yet).
BTW - when compiled with -x2 and -lcix I get a file size of 138,284 (=135k) - i.e. adding file access to stdio adds about 18k.
Ross.
It's possible that this is a bug in xbasic not a problem with the port to Catalina. I wrote xbasic (then called xgsbasic) for PIC and AVR microcontrollers and I used 16 bit integers. I recently updated it to use 32 bit integers for the Propeller and there may be bugs lingering from that conversion since I haven't done much testing yet. My standard test program is this:
10 for x=1 to 10
20 printf("%d %d\n", x, x*x)
30 next x
Yeah, I know printf doesn't seem like it belongs in Basic but that's the way it works at the moment. Once I get this 32 bit version working reliably I'm going to add dynamic string support back in and some means of interfacing with Propeller code. At least access to some of the registers like CNT, DIRA, OUTA, INA, etc.
I won't get time to do any more on this today. Today is my day for (hopefully) finishing off the Flash loader for the C3. After that I'll go back and figure out what's wrong with the XMM LARGE model on the DRACBLADE - that one's a bit odd, since I have successfully run much larger problems than this on that platform. I'm just a bit worried that I may have broken something in the 2.9 release.
After that if you're still having problems I can give you a hand with xbasic.
Ross.
Hi David,
Could be either, I suppose - but I had problems running the debugger on this program, which seems to indicate that we may both have problems!
Hi David,
Looks like the XMM.binary utility program is not working. Have you re-compiled it for the DRACBLADE?
Go to the utilities folder and type
Then copy the XMM.binary to your local folder (you won't have to do this in the next release!).
Ross.
Funny you should mention that. Yes, I did run 'build_all dracblade' but I couldn't do it in the C:\Program Files\Catalina\utilities" directory because I guess I don't have write access to that directory. The odd thing is that the batch file ran with no errors but didn't write any output files. I had to run it from a different directory.
Banner? What banner? I didn't see anything either until I put a couple of printf() calls in - maybe there is something wrong with your output function?
Ross.
This like from db_edit.c is supposed to print a banner. Ultimately, this ends up calling putchar() for each character .
VM_printf("xBasic 0.001\n");I'm using HIRES_VGA if that matters.
Aha! I just looked at your VM_printf() function, and it uses streams - stream support requires the extended library. When I compile your program with -lcix I see the banner.
Just for good measure, I typed in your 3 line basic test program - and it ran!
Congratulations!
Ross.
No worries. You could always compile your program with the PC HMI option (-D PC) and use a serial terminal emulator.
Ross.
Okay, I tried that and it's definitely faster than the ZOG version. I just wish I knew why the PS2 keyboard doesn't work. I looked at the solder joints and they look okay to me. Maybe I should try loading some simple Spin code to test it.
I can't wait to check this out.
Re the keyboard, maybe try running something simple like Kyedos just to test if it is a hardware/software issue?