Thanks - I'll incorporate it into release 2.4. There are undoubtedly more optimizations like that in the kernel that are worth doing - but at the moment I'm so busy on other stuff that the only time I go back to look at the kernel is when I have to try and find more space to add new features. This is a constant battle - not so much in the LMM kernel, but in the XMM kernel I use every single long (and you may notice I've already done a similar optimization). To include the BlackCat source code debugger functionality for XMM programs I've now had to start using the special registers above $1f0 to store data and code.
Anything else you find, please let me know.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I think I can save you another long in all ?MM code, at least if I understood the prop assembler mnemonics right:
You have two constants top8 and low24 defined. You don't need the latter if instead of "and xyz, low24" you used "andn xyz,top8" everywhere.
Another one: It looks like "all_1s" isn't actually used anywhere?
In f_d32s you could avoid the symbol :down1 and the jump there:
...
cmp r1, t2 WC,WZ
if_be sub t2, r1
if_be add r0, #1
sub t1, #1
...
The same simplification could be applied to f_d32u.
HTH,
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
This is great - keep it up, please. I have heater's ZOG project hot on my heels and need to lift my game!
all_1s is not used anywhere in the kernel itself, but is used in some instructions generated by the compiler. While it is not strictly necessary to have it in the kernel (I could generate it in hub RAM on each compile) it is done this way for speed.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I'll see what I can do. I just saw the CMPSUB instruction in the manual and think it may be used in the division functions. If I got it right, it does a CMP with the parameters swapped compared to the normal CMP. For the f_d32s function then this should work:
...
cmpsub t2,r1 WC,WZ
if_be add r0,#1
...
I have no means to test it, so I may be wrong.
The sign tests and negation of negative dividend or divisor would be simpler when you used the ABS opcode. Let me see:
There's an equivalent opcode NEGNZ which could be used instead of "if_ne neg r1,r1", but that's cosmetics.
RossH said...
all_1s is not used anywhere in the kernel itself, but is used in some instructions generated by the compiler. While it is not strictly necessary to have it in the kernel (I could generate it in hub RAM on each compile) it is done this way for speed.
Ok. I'll look through the code some more.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I'll check these out - I can't wait to see what improvements you will make when you actually get a Propeller in your hands !
Well, my order is confirmed, board will go to the mail tomorrow. I might have it by Friday or Saturday, $DEITY willing.
I have some experience with assemblers and compilers myself. The most recent things I did was writing an assembler for the Xerox Alto II, which I emulated to some degree, and so I'm acquainted with lex + yacc. I also (re-)wrote a Z80 C compiler based on ZCC; extended it with some more ANSIness, wrote a very tiny libc with some special functions for the targets I had in mind (Colour Genie and Dick Smith VZ200). This means I might be able to help here and there should there be bugs to hunt down in your lcc code.
I also have an ancient experience as a game coder back in the early 1980s. I think I can help improving the correctness of the ZiCog code, because Z80 binary is my third language besides German and English. I used to code in Z80 hex back then, having just a monitor and disassembler program as a tool to verify what I did. I also initially wrote the Z80 emulator (and several more CPU cores) for the MAME project (http://mamedev.org).
Meanwhile I have set up Catalina 2.3 and it works fine from code::blocks - after chown'ing the files in /usr/local/lib/catalina/target to my account's user:group. I don't know if this is a must or if I'm missing something else. For now I'm only looking at the assembly output (-S) to see how you translate this or that piece of C code.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Dr_Acula said...
If you can help improve the zicog, that is even better. I added EXX and EX AF, AF' but it was quite complicated.
There are still some more instructions to add.
I already peeked at the v0_10 (probably older) version of ZiCog. It's sometimes difficult to tell where the latest zips or tarballs are
I saw that this version was lacking all the undocumented opcodes. Among these are all the IX/IY half word opcodes that access LX/HX or LY/HY. Implementing these means jumping to a write back of xy_reg to either ix or iy. I know these opcodes were used in many games on e.g. the TRS-80, so adding them would make sense if anyone was going to try to emulate a specific machine on a prop.
For the EXX and EX AF,AF' opcodes, perhaps you know of the double xor trick to swap two variables without a temporary?
swap_af_af2
xor af,af2
xor af2,af
xor af,af2
...
It isn't faster or shorter than the commonly used swap using a temp, it's just that this works without a temp storage.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
It's great to see you have an interest in ZiCog. You sound like just the man we need to pull a few things straight there.
I think you will find that pretty much all the instructions implemented in ZiCog are correct. However they do not set any undocumented flag bits like a real Z80. We have been using a program from the AltairZ80 simulator project that tests instructions with huge combinations of operands and compares the results against a real Z80. There aren't many instructions that fail that test anymore.
The instructions that fail are basically not implemented, even if there is some stub code for them in there. I should really change that to cause a HALT instead of just screwing up silently.
Strangely that exerciser program has no test for EX, EXX.
An exception is DAA. It sort of works, at least enough for the CP/M SURVEY program that uses it, but if fails the test. fixing that is problematic as we have run out of room in the COG even if DAA is an overlay.
The half IX/IY ops are missing because I was going by the book. If games need them we should add them.
Basically our biggest problem is the lack of space in the COG. However I think most of the missing ops could be filled in by throwing enough overlays at it.
All Z80 registers live in HUB and have pointers to them in COG. So for the EX and EXX operations it is only necessary to change the pointers to point to the alternate registers. If the registers were positioned in HUB nicely this could be done by just XORing a bit in the pointer with 1.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm through reading the opcode descriptions now and think this is the shortest possible f_d32s implementation - for now
f_d32s
mov t1,#32
mov t2,#0 ' tmp2 is temp register to hold the remainder
mov ftemp,r1
mov ftmp2,r0
abs r1, r1
abs r0, r0
xor ftemp, ftmp2
:loop
shl r0,#1 WC
rcl t2,#1 WC
cmpsub t2,r1 WC,WZ
if_be add r0,#1
djnz t1,#:loop
mov r1,t2
mov ftmp2,ftmp2 WC ' get bit #31 into carry
negc r1,r1 ' adjust the sign of the remainder
mov ftemp,ftemp WC ' get bit #31 into carry
negc r0,r0 ' adjust the sign of the result
jmp #LMM_loop
The most recent change is to use "mov reg,reg WC" to get bit #31 into the carry, which makes the shr reg,#31 unnecessary in the first place.
BTW there's a piece of code doing division described in the propeller manual v1.1, appendix B.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
It's great to see you have an interest in ZiCog. You sound like just the man we need to pull a few things straight there.
I think you will find that pretty much all the instructions implemented in ZiCog are correct. However they do not set any undocumented flag bits like a real Z80. We have been using a program from the AltairZ80 simulator project that tests instructions with huge combinations of operands and compares the results against a real Z80. There aren't many instructions that fail that test anymore.
I see. I guess implementing the so-called X and Y flag bits would be too much for the code to fit in one cog anymore. Most of the times the X and Y flags are the corresponding bits of the most recent alu result, or the MSB of an effective address. In MAME we have a Z80 core that is tested against literally thousands of Z80 programs (games) which do all kinds of nasty things, including interrupts, NMI and Z80 peripheral stuff with Z80 CTC for example. Getting a perfect emulation of the Z80 into one cog is certainly impossible, because I guesstimate that would add something like 50% more code to the various alu ops.
heater said...
The instructions that fail are basically not implemented, even if there is some stub code for them in there. I should really change that to cause a HALT instead of just screwing up silently.
Strangely that exerciser program has no test for EX, EXX.
Well, these aren't affecting the flags, perhaps this is why they were left out.
Obviously the R register isn't tested either, as you don't have it implemented. It would increase the size of the fetch code by one instruction. Reading R yields this (counter & 0x7f) | (last written value & 0x80), which would require yet two more accessors for read and write R... i.e. too much.
heater said...
An exception is DAA. It sort of works, at least enough for the CP/M SURVEY program that uses it, but if fails the test. fixing that is problematic as we have run out of room in the COG even if DAA is an overlay.
DAA is a beast! We've had several implementations in MAME's Z80 core with the most recent doing everything exactly as the real thing. I can try to refactor this code for ZiCog.
heater said...
The half IX/IY ops are missing because I was going by the book. If games need them we should add them.
They should be easy, if you had accessors for the half IX/IY bytes. But it looks like this is going to overrun the cog memory even more.
heater said...
Basically our biggest problem is the lack of space in the COG. However I think most of the missing ops could be filled in by throwing enough overlays at it.
All Z80 registers live in HUB and have pointers to them in COG. So for the EX and EXX operations it is only necessary to change the pointers to point to the alternate registers. If the registers were positioned in HUB nicely this could be done by just XORing a bit in the pointer with 1.
I see. I'll have a look at ZiCog to see if I can find anything to squeeze a little more in there.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Meanwhile I have set up Catalina 2.3 and it works fine from code::blocks - after chown'ing the files in /usr/local/lib/catalina/target to my account's user:group. I don't know if this is a must or if I'm missing something else. For now I'm only looking at the assembly output (-S) to see how you translate this or that piece of C code.
Yes, the permissions on the files in the target directory is a known issue under Linux - I hope to fix it in the next release.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Posted 9/29/2009 2:52 PM
>> If anyone manages to compile Catalina on other platforms (e.g. OSX or 64 bit Windows) please post your
>> instructions/experiences here.
>>
>> Ross.
using the 12_29_2009_catalina_linux_source.tgz, catalina compiles & runs fine under freebsd/x86.
the obvious change needed is using gmake (GNU make) instead of BSD make.
one thing that tripped me up, that seems to be required
(someone more familiar with the source can surely do a better patch):
in lcc/cpp/include.c
# around line 92, right after:
strcpy(iname, ip->file);
# and right before
strcat(iname, "/");
strcat(iname, fname);
# I added the lines:
if ( \
( strlen(iname) ) && \
( iname[noparse][[/noparse]0] == '\"' ) && \
( iname[noparse][[/noparse] strlen(iname)-1 ] == '\"' ) \
) {
/* kill the quotes around include filenames.
without this, when compiling ../lib, I get stuff like:
trying (1) "../include"/assert.h
trying (2) "..\include"\assert.h
cpp: assert.c:6 Could not find include file <assert.h>
*/
/* according to FreeBSD manpages, memmove() allows the strings to
overlap, while memcpy() does on some systems, but not all.
I'm not sure what the relevant standards say.
*/
memmove( iname, iname+1, strlen(iname)-2 );
iname[noparse][[/noparse] strlen(iname)-2 ] = '\0';
}
I did not use tar -p, and extracted & compiled under my home dir (as non-root user).
although this required changing 10 or so hard-coded /usr/local/lib/catalina in the sources/makefiles/etc.,
everything seems to run fine for me, no permissions problems.
Just an FYI -- I don't know what permissions problems others are having.
One question I have: is there a way to use -E (output preprocessed C source code) but also
use -o (output to a file) rather than sending it to stdout?
(I can redirect stdout to a file, but Catalina, even without verbose, seems to append a line or two).
I'm not sure if this is a catalina or lcc or cpp issue.
Gives me the same-sized binaries though (doing "compile in a single batch" alone sometimes
helps gcc and others reduce code size, it seems lcc/catalina already do a good job here though).
Just saying CMI is very nice, and code size can sometimes be reduced substantially.
One more question:
regarding the "cable you need to flash a new "firmware" on to a
HYDRA XTREME 512K SRAM Card so catalina can use all 512K"
I'll have a look at your proposed changes to the makefile for inclusion in the next release. Thanks for the feedback.
CMI looks very useful. If you use a command like
catalina -E hello_world.c > preprocessed.c
the only extra line you should get is the banner line (e.g. "Catalina Compiler 2.3") as the last line. I can modify the next release of Catalina to direct the banner line and other Catalina output to stderr instead of stdout so that it doesn't get mixed up with the source code when you use -E and redirect stdout. If you can't wait, then you can easily modify the Catalina source to remove the output of the banner line altogether (the file to modify is catalina.c in the 'source\catalina' directory).
The Linux (and Vista) permission problems only tend to show up if you install Catalina as root and then try and use it from a non-root user account. But I've fixed these problems already - I will include the fix in the next release.
If I recall correctly, the software required for loading new firmware in the HX512 is included on the CD provided with the HX512. It runs under Windows only. If you can't find it, let me know and I can send you a copy.
A copy of Eric Moyer's modified HX512 firmware is provided with Catalina (it's in a zip file in the 'utilities' directory).
The HX512 documentation contains details of the programming cable required, but I found it much cheaper to make my own - instructions are provided in the HX512 documentation (but see here for some minor omissions and updates to those instructions).
Good luck!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Here is a summary of the major functional changes:
Support for two source level debuggers - BlackBox and BlackCat.
BlackBox is a command line debugger that runs under Linux or Windows, and is included with this release.
BlackCat is a graphical debugger for Windows, developed by Bob Anderson, and is available here.
Support for ViewPort. Note that you need the latest release of ViewPort available here.
A new program loader - Payload. Payload runs under Linux or Windows, and can load normal programs, or Catalina LMM and XMM programs using a serial connection from a PC.
Improved multi-user support under both Windows (esp. Vista & Windows 7) and Linux.
Various bug fixes and minor improvements (see the README.WhatsNew file attached to the top post for details).
Improved documentation - including a new tutorial style introduction to Code::Blocks and BlackBox, and a BlackBox Reference Manual (the Payload documentation is included in the Catalina Reference Manual).
The source level debugger support has taken so long that several things that were originally going to be included in this release haven't made it - they will be held over to release 2.5:
Kernel optimizations (apologies,Juergen - I promise your improvements will be in the next release!)
Command line arguments.
Multithreading support.
See the top post in this thread for more details, and the sources and binaries.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I used the latest version of WinZip to create the zip files. Because of the forum limitations, I have to let WinZip split the zip file into chunks no larger than 2Mb. If you download a recent version of WinZip and run it on the main .zip file, it should unzip all the chunks automatically.
You probably can't use RAR or 7-Zip on these type of archives.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Reload files from FORUM to You and test if You unpack them correctly.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
It works fine for me, I downloaded two files a .zip and a .z01.
I just extracted the .zip to a new folder everything was fine.
I am using Winzip Pro 11.1
Regards,
Coley
PS Nice work Ross!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ PropGFX - The home of the Hybrid Development System and PropGFX Lite
Dwnloaded 14.0
And it function - Must look for update of WinRar.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
I've just released a small patch to Release 2.4 to add BlackBox support for a couple of missing features. See the first post in this thread for the download. Here are the details.
PATCH RELEASE - 5 Apr 2010
===================
This patch release contains a new version of BlackBox which includes full support for bit fields, and also for C files that '#include' other C files.
This patch is applicable to both Linux and Windows distributions - just unzip the zip file over the top of your existing 2.4 distribution - no need to rebuild Catalina.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Apologies - I've had to re-issue the patch I issued yesterday because I found a Catalina bug while testing the new version of BlackBox. If you have already downloaded the old patch release, please download and unzip the new one - it completely supersedes it. As usual, the file to download is attached to the first post in this thread.
Here are the updated details:
PATCH RELEASE - 6 Apr 2010
===================
This patch release contains a new version of LCC which fixes a bug related to signed integer manipulation, some replacement compiled library functions that were affected by the bug, and a new version of BlackBox which includes full support for bit fields, and also for C files that '#include' other C files.
This patch is applicable to both Linux and Windows distributions, and contains both binaries and source - just unzip the attached zip file over the top of your existing 2.4 distribution - no need to rebuild Catalina. However, if you are using Linux, there are some permissions that will need adjusting - see the README.Patch_6_Apr_10 included in the zip file for details.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I have posted a new patch release - dated 8 Apr 10 - to the first post of this thread. The main reason for this patch is that it resolves the problem some people were experiencing using Payload on some platforms (mainly Vista and Windows 7, although it may have also affected some Windows XP users).
This patch is cumulative - i.e. it includes all the prior patches since release 2.4. I think I will do patch releases this way from now on, as it means you only ever have to download the latest patch release.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I have just release a new patch - dated 20 Apr 10 - to fix a single bug. Here are the relevant details:
a fix for a bug in the BlackBox/BlackCat support target that affected XMM programs compiled with the -x5 option. The most common symptom is that the video display is not initialized properly when the program is started - i.e. no output would appear - even though the debugger appeared to work and could step through the program line by line. May also have affected the keyboard.
The patch is cumulative - i.e. it contains all prior patches. Just apply it over your existing Catalina 2.4 distribution. Under Linux you may need to change some file permissions - see the README contained in the patch.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
The first full release of Catalyst (the enhanced Catalina program loader described in this thread) is nearly ready, but I have decided that it makes sense to use Kye's FATEngine for the program loader in place of the current FSRW. The main reason for this is that both Catalina (which uses the DOSFS embedded file system) and FATEngine support subdirectories - but FSRW does not.
Using FATEngine will make Catalyst consistent with Catalina. As things stand at the moment (i.e. with the Catalyst program loader using FSRW) you can only load programs from the root directory of an SD card - but once those programs are running can then they can access files in subdirectories (whether they are implemented in SPIN and use FATEngine or in C and use DOSFS).
This means that I am now expecting I will wait till Kye has some time to update his FATEngine before the formal Catalyst release - which means that I have a window of a couple of weeks to make other improvements in Catalina.
Already on my "to do" list for the next release are support for the XMM RAM on Cluso's RamBlade, and the performance improvements (including those proposed by Pullmoll earlier in this thread). I'm still hoping to improve the Code::Blocks support, but that is probably too ambitious for this release.
If anybody has any specific requests or features they would like to see included (or really annoying things they would like to see improved!) please let me know and I'll see if I can fit them in.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Comments
Thanks - I'll incorporate it into release 2.4. There are undoubtedly more optimizations like that in the kernel that are worth doing - but at the moment I'm so busy on other stuff that the only time I go back to look at the kernel is when I have to try and find more space to add new features. This is a constant battle - not so much in the LMM kernel, but in the XMM kernel I use every single long (and you may notice I've already done a similar optimization). To include the BlackCat source code debugger functionality for XMM programs I've now had to start using the special registers above $1f0 to store data and code.
Anything else you find, please let me know.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 3/2/2010 11:13:40 PM GMT
Hey Ross,
I think I can save you another long in all ?MM code, at least if I understood the prop assembler mnemonics right:
You have two constants top8 and low24 defined. You don't need the latter if instead of "and xyz, low24" you used "andn xyz,top8" everywhere.
Another one: It looks like "all_1s" isn't actually used anywhere?
In f_d32s you could avoid the symbol :down1 and the jump there:
... cmp r1, t2 WC,WZ if_be sub t2, r1 if_be add r0, #1 sub t1, #1 ...The same simplification could be applied to f_d32u.
HTH,
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/3/2010 12:22:07 AM GMT
This is great - keep it up, please. I have heater's ZOG project hot on my heels and need to lift my game!
all_1s is not used anywhere in the kernel itself, but is used in some instructions generated by the compiler. While it is not strictly necessary to have it in the kernel (I could generate it in hub RAM on each compile) it is done this way for speed.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I'll see what I can do. I just saw the CMPSUB instruction in the manual and think it may be used in the division functions. If I got it right, it does a CMP with the parameters swapped compared to the normal CMP. For the f_d32s function then this should work:
... cmpsub t2,r1 WC,WZ if_be add r0,#1 ...I have no means to test it, so I may be wrong.
The sign tests and negation of negative dividend or divisor would be simpler when you used the ABS opcode. Let me see:
... mov ftemp, r1 mov ftmp2, r2 abs r1, ftemp abs r2, ftmp2 xor ftemp, ftmp2 shr ftemp,#31 shr ftmp2,#31 ...Before: 11 opcodes, after: 7 opcodes, savings: 4 longs.
Likewise the final sign changes could be done using the NEG opcode instead of the lengthy subtraction from t2.
... mov r1,t2 cmp ftmp2,#0 WZ if_ne neg r1,r1 cmp ftemp,#0 WZ if_ne neg r0,r0 jmp #LMM_loop ....
Before: 10 opcodes, after: 6 opcodes, savings: 4 longs.
There's an equivalent opcode NEGNZ which could be used instead of "if_ne neg r1,r1", but that's cosmetics.
Ok. I'll look through the code some more.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/3/2010 7:48:59 AM GMT
I'll check these out - I can't wait to see what improvements you will make when you actually get a Propeller in your hands !
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Well, my order is confirmed, board will go to the mail tomorrow. I might have it by Friday or Saturday, $DEITY willing.
I have some experience with assemblers and compilers myself. The most recent things I did was writing an assembler for the Xerox Alto II, which I emulated to some degree, and so I'm acquainted with lex + yacc. I also (re-)wrote a Z80 C compiler based on ZCC; extended it with some more ANSIness, wrote a very tiny libc with some special functions for the targets I had in mind (Colour Genie and Dick Smith VZ200). This means I might be able to help here and there should there be bugs to hunt down in your lcc code.
I also have an ancient experience as a game coder back in the early 1980s. I think I can help improving the correctness of the ZiCog code, because Z80 binary is my third language besides German and English. I used to code in Z80 hex back then, having just a monitor and disassembler program as a tool to verify what I did. I also initially wrote the Z80 emulator (and several more CPU cores) for the MAME project (http://mamedev.org).
Meanwhile I have set up Catalina 2.3 and it works fine from code::blocks - after chown'ing the files in /usr/local/lib/catalina/target to my account's user:group. I don't know if this is a must or if I'm missing something else. For now I'm only looking at the assembly output (-S) to see how you translate this or that piece of C code.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Excellent news. Though for me the order is English, Z80, German!
If you can help improve the zicog, that is even better. I added EXX and EX AF, AF' but it was quite complicated.
There are still some more instructions to add.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I already peeked at the v0_10 (probably older) version of ZiCog. It's sometimes difficult to tell where the latest zips or tarballs are
I saw that this version was lacking all the undocumented opcodes. Among these are all the IX/IY half word opcodes that access LX/HX or LY/HY. Implementing these means jumping to a write back of xy_reg to either ix or iy. I know these opcodes were used in many games on e.g. the TRS-80, so adding them would make sense if anyone was going to try to emulate a specific machine on a prop.
For the EXX and EX AF,AF' opcodes, perhaps you know of the double xor trick to swap two variables without a temporary?
swap_af_af2 xor af,af2 xor af2,af xor af,af2 ...It isn't faster or shorter than the commonly used swap using a temp, it's just that this works without a temp storage.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/3/2010 2:10:35 PM GMT
It's great to see you have an interest in ZiCog. You sound like just the man we need to pull a few things straight there.
I think you will find that pretty much all the instructions implemented in ZiCog are correct. However they do not set any undocumented flag bits like a real Z80. We have been using a program from the AltairZ80 simulator project that tests instructions with huge combinations of operands and compares the results against a real Z80. There aren't many instructions that fail that test anymore.
The instructions that fail are basically not implemented, even if there is some stub code for them in there. I should really change that to cause a HALT instead of just screwing up silently.
Strangely that exerciser program has no test for EX, EXX.
An exception is DAA. It sort of works, at least enough for the CP/M SURVEY program that uses it, but if fails the test. fixing that is problematic as we have run out of room in the COG even if DAA is an overlay.
The half IX/IY ops are missing because I was going by the book. If games need them we should add them.
Basically our biggest problem is the lack of space in the COG. However I think most of the missing ops could be filled in by throwing enough overlays at it.
All Z80 registers live in HUB and have pointers to them in COG. So for the EX and EXX operations it is only necessary to change the pointers to point to the alternate registers. If the registers were positioned in HUB nicely this could be done by just XORing a bit in the pointer with 1.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm through reading the opcode descriptions now and think this is the shortest possible f_d32s implementation - for now
f_d32s mov t1,#32 mov t2,#0 ' tmp2 is temp register to hold the remainder mov ftemp,r1 mov ftmp2,r0 abs r1, r1 abs r0, r0 xor ftemp, ftmp2 :loop shl r0,#1 WC rcl t2,#1 WC cmpsub t2,r1 WC,WZ if_be add r0,#1 djnz t1,#:loop mov r1,t2 mov ftmp2,ftmp2 WC ' get bit #31 into carry negc r1,r1 ' adjust the sign of the remainder mov ftemp,ftemp WC ' get bit #31 into carry negc r0,r0 ' adjust the sign of the result jmp #LMM_loopThe most recent change is to use "mov reg,reg WC" to get bit #31 into the carry, which makes the shr reg,#31 unnecessary in the first place.
BTW there's a piece of code doing division described in the propeller manual v1.1, appendix B.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I see. I guess implementing the so-called X and Y flag bits would be too much for the code to fit in one cog anymore. Most of the times the X and Y flags are the corresponding bits of the most recent alu result, or the MSB of an effective address. In MAME we have a Z80 core that is tested against literally thousands of Z80 programs (games) which do all kinds of nasty things, including interrupts, NMI and Z80 peripheral stuff with Z80 CTC for example. Getting a perfect emulation of the Z80 into one cog is certainly impossible, because I guesstimate that would add something like 50% more code to the various alu ops.
Well, these aren't affecting the flags, perhaps this is why they were left out.
Obviously the R register isn't tested either, as you don't have it implemented. It would increase the size of the fetch code by one instruction. Reading R yields this (counter & 0x7f) | (last written value & 0x80), which would require yet two more accessors for read and write R... i.e. too much.
DAA is a beast! We've had several implementations in MAME's Z80 core with the most recent doing everything exactly as the real thing. I can try to refactor this code for ZiCog.
They should be easy, if you had accessors for the half IX/IY bytes. But it looks like this is going to overrun the cog memory even more.
I see. I'll have a look at ZiCog to see if I can find anything to squeeze a little more in there.
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Yes, the permissions on the files in the target directory is a known issue under Linux - I hope to fix it in the next release.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
using the 12_29_2009_catalina_linux_source.tgz, catalina compiles & runs fine under freebsd/x86.
the obvious change needed is using gmake (GNU make) instead of BSD make.
one thing that tripped me up, that seems to be required
(someone more familiar with the source can surely do a better patch):
in lcc/cpp/include.c # around line 92, right after: strcpy(iname, ip->file); # and right before strcat(iname, "/"); strcat(iname, fname); # I added the lines: if ( \ ( strlen(iname) ) && \ ( iname[noparse][[/noparse]0] == '\"' ) && \ ( iname[noparse][[/noparse] strlen(iname)-1 ] == '\"' ) \ ) { /* kill the quotes around include filenames. without this, when compiling ../lib, I get stuff like: trying (1) "../include"/assert.h trying (2) "..\include"\assert.h cpp: assert.c:6 Could not find include file <assert.h> */ /* according to FreeBSD manpages, memmove() allows the strings to overlap, while memcpy() does on some systems, but not all. I'm not sure what the relevant standards say. */ memmove( iname, iname+1, strlen(iname)-2 ); iname[noparse][[/noparse] strlen(iname)-2 ] = '\0'; }I did not use tar -p, and extracted & compiled under my home dir (as non-root user).
although this required changing 10 or so hard-coded /usr/local/lib/catalina in the sources/makefiles/etc.,
everything seems to run fine for me, no permissions problems.
Just an FYI -- I don't know what permissions problems others are having.
One question I have: is there a way to use -E (output preprocessed C source code) but also
use -o (output to a file) rather than sending it to stdout?
(I can redirect stdout to a file, but Catalina, even without verbose, seems to append a line or two).
I'm not sure if this is a catalina or lcc or cpp issue.
I like to use http://www.cs.utah.edu/flux/knit/cmi.html is why I am wondering.
I got it working, just my way of getting preprocessed source
code seems a little hackish & fragile at the moment.
Thank you!
but using CMI I can get e.g. one of my executables to go from ~200kb down to ~32kb.
Having catalina itself compile all code in a single batch, e.g.
catalina 1.c 2.c 3.c -o out
versus
catalina -c 1.c
catalina -c 2.c
catalina -c 3.c
catalina 1.o 2.o 3.o -o out
Gives me the same-sized binaries though (doing "compile in a single batch" alone sometimes
helps gcc and others reduce code size, it seems lcc/catalina already do a good job here though).
Just saying CMI is very nice, and code size can sometimes be reduced substantially.
One more question:
regarding the "cable you need to flash a new "firmware" on to a
HYDRA XTREME 512K SRAM Card so catalina can use all 512K"
I found:
http://www.latticesemi.com/store/programming_hw.cfm
Yes ispDOWNLOAD Cable (Parallel Port - RoHS Compliant)
HW-DLN-3C $65.00
Yes ispDOWNLOAD Cable (USB - RoHS Compliant)
HW-USBN-2A $149.00
Will either of those cables work? Does anyone know a better price or where I might
find one used?
Also, what software is needed to do the "update"? Is it freely available?
Is it windows-only?
Thanks!
I'll have a look at your proposed changes to the makefile for inclusion in the next release. Thanks for the feedback.
CMI looks very useful. If you use a command like
the only extra line you should get is the banner line (e.g. "Catalina Compiler 2.3") as the last line. I can modify the next release of Catalina to direct the banner line and other Catalina output to stderr instead of stdout so that it doesn't get mixed up with the source code when you use -E and redirect stdout. If you can't wait, then you can easily modify the Catalina source to remove the output of the banner line altogether (the file to modify is catalina.c in the 'source\catalina' directory).
The Linux (and Vista) permission problems only tend to show up if you install Catalina as root and then try and use it from a non-root user account. But I've fixed these problems already - I will include the fix in the next release.
If I recall correctly, the software required for loading new firmware in the HX512 is included on the CD provided with the HX512. It runs under Windows only. If you can't find it, let me know and I can send you a copy.
A copy of Eric Moyer's modified HX512 firmware is provided with Catalina (it's in a zip file in the 'utilities' directory).
The HX512 documentation contains details of the programming cable required, but I found it much cheaper to make my own - instructions are provided in the HX512 documentation (but see here for some minor omissions and updates to those instructions).
Good luck!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I have just released Catalina 2.4.
Here is a summary of the major functional changes:
- Support for two source level debuggers - BlackBox and BlackCat.
- BlackBox is a command line debugger that runs under Linux or Windows, and is included with this release.
- BlackCat is a graphical debugger for Windows, developed by Bob Anderson, and is available here.
- Support for ViewPort. Note that you need the latest release of ViewPort available here.
- A new program loader - Payload. Payload runs under Linux or Windows, and can load normal programs, or Catalina LMM and XMM programs using a serial connection from a PC.
- Improved multi-user support under both Windows (esp. Vista & Windows 7) and Linux.
- Various bug fixes and minor improvements (see the README.WhatsNew file attached to the top post for details).
- Improved documentation - including a new tutorial style introduction to Code::Blocks and BlackBox, and a BlackBox Reference Manual (the Payload documentation is included in the Catalina Reference Manual).
The source level debugger support has taken so long that several things that were originally going to be included in this release haven't made it - they will be held over to release 2.5:See the top post in this thread for more details, and the sources and binaries.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 4/2/2010 11:36:43 PM GMT
I have problems to unpack binaries.
! H:\Arbets\_Div Spin Code\-_ HardWare\HardWare\Catalina - a C compiler for the Propeller\2.4\catalina_win32_binary.z01: Kan inte
I used the latest version of WinZip to create the zip files. Because of the forum limitations, I have to let WinZip split the zip file into chunks no larger than 2Mb. If you download a recent version of WinZip and run it on the main .zip file, it should unzip all the chunks automatically.
You probably can't use RAR or 7-Zip on these type of archives.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I never had problems with that files.
Reload files from FORUM to You and test if You unpack them correctly.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
It works fine for me, I downloaded two files a .zip and a .z01.
I just extracted the .zip to a new folder everything was fine.
I am using Winzip Pro 11.1
Regards,
Coley
PS Nice work Ross!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX - The home of the Hybrid Development System and PropGFX Lite
Dwnloaded 14.0
And it function - Must look for update of WinRar.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
I'll add a note to the downloads that you need at WinZip version 10 or later to deal with the split archives.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I've just released a small patch to Release 2.4 to add BlackBox support for a couple of missing features. See the first post in this thread for the download. Here are the details.
PATCH RELEASE - 5 Apr 2010
===================
This patch release contains a new version of BlackBox which includes full support for bit fields, and also for C files that '#include' other C files.
This patch is applicable to both Linux and Windows distributions - just unzip the zip file over the top of your existing 2.4 distribution - no need to rebuild Catalina.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 4/6/2010 12:42:07 AM GMT
Apologies - I've had to re-issue the patch I issued yesterday because I found a Catalina bug while testing the new version of BlackBox. If you have already downloaded the old patch release, please download and unzip the new one - it completely supersedes it. As usual, the file to download is attached to the first post in this thread.
Here are the updated details:
PATCH RELEASE - 6 Apr 2010
===================
This patch release contains a new version of LCC which fixes a bug related to signed integer manipulation, some replacement compiled library functions that were affected by the bug, and a new version of BlackBox which includes full support for bit fields, and also for C files that '#include' other C files.
This patch is applicable to both Linux and Windows distributions, and contains both binaries and source - just unzip the attached zip file over the top of your existing 2.4 distribution - no need to rebuild Catalina. However, if you are using Linux, there are some permissions that will need adjusting - see the README.Patch_6_Apr_10 included in the zip file for details.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 4/6/2010 1:27:41 PM GMT
I have posted a new patch release - dated 8 Apr 10 - to the first post of this thread. The main reason for this patch is that it resolves the problem some people were experiencing using Payload on some platforms (mainly Vista and Windows 7, although it may have also affected some Windows XP users).
This patch is cumulative - i.e. it includes all the prior patches since release 2.4. I think I will do patch releases this way from now on, as it means you only ever have to download the latest patch release.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I have just release a new patch - dated 20 Apr 10 - to fix a single bug. Here are the relevant details:
The patch is cumulative - i.e. it contains all prior patches. Just apply it over your existing Catalina 2.4 distribution. Under Linux you may need to change some file permissions - see the README contained in the patch.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
The first full release of Catalyst (the enhanced Catalina program loader described in this thread) is nearly ready, but I have decided that it makes sense to use Kye's FATEngine for the program loader in place of the current FSRW. The main reason for this is that both Catalina (which uses the DOSFS embedded file system) and FATEngine support subdirectories - but FSRW does not.
Using FATEngine will make Catalyst consistent with Catalina. As things stand at the moment (i.e. with the Catalyst program loader using FSRW) you can only load programs from the root directory of an SD card - but once those programs are running can then they can access files in subdirectories (whether they are implemented in SPIN and use FATEngine or in C and use DOSFS).
This means that I am now expecting I will wait till Kye has some time to update his FATEngine before the formal Catalyst release - which means that I have a window of a couple of weeks to make other improvements in Catalina.
Already on my "to do" list for the next release are support for the XMM RAM on Cluso's RamBlade, and the performance improvements (including those proposed by Pullmoll earlier in this thread). I'm still hoping to improve the Code::Blocks support, but that is probably too ambitious for this release.
If anybody has any specific requests or features they would like to see included (or really annoying things they would like to see improved!) please let me know and I'll see if I can fit them in.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Hi Ross,
I just looked a little bit at catallina, but I couldn't find "inttypes.h".
In my programs I allways use this type of variable definitions like
uint8_t, uint16_t, int8_t ....
In my opinion it is the best way to program C.
best regards,
chris
The "inttypes.h" header is a C99 feature - but it is easy enough to add a C89 version for the basic types. I'll include one in the next release.
Thanks,
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Not being above a little bit of shameless self-promotion, I just thought I'd point out that Catalina is "Project of the Week" this week.
Also, congratulations to Bob Anderson, because his BlackCat source code debugger is also "Object of the Week".
A quinella for C programmers!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 5/14/2010 9:56:25 AM GMT