Umm ... you mean something like the "Getting Started with CodeBlocks" document? But basically yes, I agree with you. I will see what I can do.
I was pondering this last night, and I wonder if one very simple change to the install process could solve all the problems I had and make it easier for a beginner. In the install process a number of screens come up in sequence. I wonder if you could add one more that simply says "View Readme now" or "View documentation now" and a little check box?
Default is the box is checked, and if it is checked, it opens up the getting started document.
And fairly early on in the document, some screenshots or whatever about how to set it up for your particular hardware (C3, gadget gangster, hydra or whatever).
Specifying the HMI options you would like supported on a particular platform is now simpler in Catalina 3.1.
Attached is a replacement DracBlade_HMI.inc that enables the TV drivers on the DracBlade. The default driver is still the VGA driver, so to actually use the TV drivers you must specify either -D TV, -D HIRES_TV or -D LORES_TV on the command line (or select the appropriate check box in Code::Blocks).
This file also disables the mouse driver, so you don't need to specify -D NO_MOUSE on each compile.
To modify the pins assigned to the TV output, you edit the file DracBlade_DEF.inc (also in the target folder). I have attached a version that uses pins 17, 18, 19 (as per your request).
Just copy the attached files over the existing files in the target folder.
As per Dr_Acula's suggestions, I have updated the new Catalina 3.1 Windows installer (on SourceForge) so that it now displays a new CodeBlocks QuickStart guide on completion of the install (assuming you chose to install Code::Blocks).
The Quickstart guides you through starting Code::Blocks for the first time, and then creating, compiling and downloading your first "hello world" type C application.
This guide contains a subset of the informationin Getting Started with CodeBlocks, but hopefully doing it this way means some users may actually read it!
I had a free moment at work so I took the opportunity to do a new download of Catalina. The process has gone extremely smoothly. (Don't tell my boss though *grin*)
1) Go to post #30 on this thread, and click the link at the top of that post. The download starts automatically.
2) Answer the questions. The Help manual opens automatically (Thanks++ Ross for adding that feature)
3) Follow the instructions.
There are two things I wanted to check out
1) Changing all the text highlighting colors and options. (settings/editor and on the left four down, syntax highlighting) This can be done in code::blocks, so if you don't like the color purple, change it to something else. Nifty!
2) A problem I was getting with a huge C program is finding my way around the program. But in code:blocks there are little minus signs that appear for each block of code, and you can shrink these blocks down. This means that once a function is working you can hide it. (I think this is called 'folding')
IMHO this is extremely useful. It means you can really concentrate on a few functions that might be interacting with each other (probably the Main and a sub function) and have them on the same screen.
This is really going to speed up development. And I really appreciate this feature because I tried for some months to find a way to code it in vb.net in my IDE and never really found a satisfactory solution (ditto syntax highlighting, which I got working but only slowly). So I am very pleased to see these features in code::blocks.
I tried finding the link on sourceforge to the 'setup' single click link but I couldn't find it. I was wondering, since this is such a quantum leap in terms of ease of use, whether the contents of post #30 on this thread might warrant being replicated on post #1 of a new thread, so we (ok, me) can find it in future if I forget that it is hidden inside this thread?
Cheers, (and thanks++ again to Ross for making this happen)
Yes, I knew about this one. From memory, the FLT_MAX constant defined in float.h is actually a 64 bit value, whereas Catalina floats are 32 bits. I think it works just as well, since you end up with the equivalent 32 bit FLT_MAX value - but it does throw a compiler warning. I left the 64 bit value in there since I was (at one stage) considering supporting 64 bit floating point - but there doesn't seem to be much call for 64 bit floating point on the Propeller , so I should really fix it. Thanks for reminding me.
A 64-bit floating point type would be double, not float anyway, wouldn't it? That's pretty much universal.
FLT_MAX on *nix is 32 bits, DBL_MAX is 64 bits, e.g. from IRIX:
limits.h:232:#define FLT_MAX 3.40282347E+38F /* max decimal value of a "float" */
limits.h:228:#define DBL_MAX 1.7976931348623157E+308 /* max decimal value of a "double"*/
A 64-bit floating point type would be double, not float anyway, wouldn't it? That's pretty much universal.
FLT_MAX on *nix is 32 bits, DBL_MAX is 64 bits, e.g. from IRIX:
limits.h:232:#define FLT_MAX 3.40282347E+38F /* max decimal value of a "float" */
limits.h:228:#define DBL_MAX 1.7976931348623157E+308 /* max decimal value of a "double"*/
-Tor
Hi Tor,
I don't believe the C standard specifies that floats have to be 32 bits and doubles 64 bits. It is quite acceptable for both to be 32 (as in Catalina) or both to be 64 bits. In fact, the size is not specified in bits at all - the standard just specifies the range and precision that must be able to be represented.
In any case, the problem is not quite what I remembered (although, it is true that Catalina generates the correct value internally, despite throwing the overflow warning - I remember testing that!). I had remembered to use a FLT_MAX value appropriate to 32 bit floats, but I made the same mistake your IRIX include files made - i.e. both the Catalina and the IRIX values are in fact incorrect, and this shows up if the compiler is run on a machine which itself has 32 bit floats!
The correct value for an IEEE754 32 bit FLT_MAX (when using extended precision) is actually 3.4028234663852886E+38. Rounding that value up to 3.40282347E+38 is what is causing the overflow warning - even though it generates (bit for bit) the correct 32 bit internal representation!
You would probably not get the warning at all on a maching that used 64 bit representations of all floating point values during compilation - this is probably why the incorrect value works on IRIX.
For the moment, Catalina will throw the overflow warning (but generate the correct value!) if FLT_MAX is used. I willl fix this in the next release.
I don't believe the C standard specifies that floats have to be 32 bits and doubles 64 bits. It is quite acceptable for both to be 32 (as in Catalina) or both to be 64 bits. In fact, the size is not specified in bits at all - the standard just specifies the range and precision that must be able to be represented.
Hi Ross,
It's correct that ANSI C only specifies a minimum precision for each type, but IEEE 754 specifies single precision and double precision as 32- and 64 bit respectively, and any architecture compatible with IEEE 754 will thus in practice have to use a 32-bit "float" type and a 64-bit "double" type. I don't think I've seen anything reasonably modern that doesn't use 32 bits for float and 64 bits for double, not even for architectures which are not IEEE 754 compatible.
In any case, the problem is not quite what I remembered (although, it is true that Catalina generates the correct value internally, despite throwing the overflow warning - I remember testing that!). I had remembered to use a FLT_MAX value appropriate to 32 bit floats, but I made the same mistake your IRIX include files made - i.e. both the Catalina and the IRIX values are in fact incorrect, and this shows up if the compiler is run on a machine which itself has 32 bit floats!
The correct value for an IEEE754 32 bit FLT_MAX (when using extended precision) is actually 3.4028234663852886E+38. Rounding that value up to 3.40282347E+38 is what is causing the overflow warning - even though it generates (bit for bit) the correct 32 bit internal representation!
Tru64 (DEC) also uses the same definition as IRIX. AIX uses the longer value you listed, and Solaris uses an even longer one (3.4028234663852885981170E+38F).
You would probably not get the warning at all on a maching that used 64 bit representations of all floating point values during compilation - this is probably why the incorrect value works on IRIX.
I'm not sure about that - the 'F' at the end is supposed to tell the compiler that the value shall be handled as single precision all the way, presumably also during compilation. In any case none of the architectures listed will give a warning. This is of course mostly a technicality though.
Hi Ross,
It's correct that ANSI C only specifies a minimum precision for each type, but IEEE 754 specifies single precision and double precision as 32- and 64 bit respectively, and any architecture compatible with IEEE 754 will thus in practice have to use a 32-bit "float" type and a 64-bit "double" type. I don't think I've seen anything reasonably modern that doesn't use 32 bits for float and 64 bits for double, not even for architectures which are not IEEE 754 compatible.
Hi Tor,
It is true that if you are using IEEE754 then your only choices of sizes are 32 or 64 bit - but that doesn't mean a C compiler has to choose 32 bit as float size and 64 bit as a double. A float can be 64 bit, or a double can be 32 bit. (although I think there is probably a requirement that a float be able to be converted to a double and back again without losing precision, which means the available choices for float/double sizes are 32/32, 64/64 or 32/64 - but not 64/32).
Tru64 (DEC) also uses the same definition as IRIX. AIX uses the longer value you listed, and Solaris uses an even longer one (3.4028234663852885981170E+38F).
...
the 'F' at the end is supposed to tell the compiler that the value shall be handled as single precision all the way, presumably also during compilation. In any case none of the architectures listed will give a warning. This is of course mostly a technicality though.
-Tor
Now you are really getting into the innards - but it's quite interesting
To understand the meaning of the "F" at the end of such a high precision constant, consider it this way: if your compiler processes floating point constants as 32 bits during parsing then it cannot even successfully represent a declaration such as 3.4028234663852885981170E+38F - the 32 bit float would overflow as soon as it got beyond about the 10th digit. But a compiler can internally represent such constants as 64 bit values, treating the F as meaning that they should be truncated to 32 bit values after parsing (or perhaps even later - during the actual code generation). Then everything works as you see on Tru64, Solaris and IRIX.
There are also other ways of coping with this problem, but I believe the latter is how many C compilers actually work - i.e.all floating point constants are represented internally during code parsing and generation to the maximum machine representation (which is typically 64 bits). In such cases, all the definitions of FLT_MAX we have been discussing will work. The problem we see with Catalina arises only if the compiler tries to represent all 32 bit constants internally as 32 bits. In that case, all the definitions of FLT_MAX we have been discussing will in fact overflow during compile.
You are right, of course - the compilers will be written so that you won't get actual runtime warnings from the compiler itself. I didn't actually test that case with Catalina, so I thought you explictly generated a warning when parsing - but it's actually a runtime warning? In any case, I suspect we're way beyond what's interesting for the other readers of this thread..
I have been avoiding the upgrade, because I had gotten very comfortable with Catalina 2.9 and CodeBlocks. Thankyou for the BETA_Catalina_3.1_Setup. It workes like a Charm !
I do have a problem with the Catalyst install though. When I run the following, build_all RAMBLADE PC VT100 ,from the Catalyst folder, I get and error "MSYS not in the current path !!"
I have used Catalyst with Catalina 2.9, that's history now.
I have read your notes re- issues with MSYS and windoze 7 and taken them onboard, but at this stage I have not been able to build a Catalyst.binary file.
I have been avoiding the upgrade, because I had gotten very comfortable with Catalina 2.9 and CodeBlocks. Thankyou for the BETA_Catalina_3.1_Setup. It workes like a Charm !
I do have a problem with the Catalyst install though. When I run the following, build_all RAMBLADE PC VT100 ,from the Catalyst folder, I get and error "MSYS not in the current path !!"
I have used Catalyst with Catalina 2.9, that's history now.
I have read your notes re- issues with MSYS and windoze 7 and taken them onboard, but at this stage I have not been able to build a Catalyst.binary file.
Any thoughts ?
Ron
Hi Ron,
Building the Catalyst demos requires make (Catalyst itself does not, but some of the demos do). If I cannot find the 'make' executable then I print that error. I'm not sure what version of MinGW/MSYS you have, but I do recall that in some versions the installation of MinGW 'make' was an optional component and you had to select it during install. Please ensure you have it installed, and that both the MinGW and MSYS 'bin' directories are in your current path.
I had downloaded a new version of MinGW and didn't reset the path to the new location (
Problem fixed.
Thanks again.
Ron
Hi Ron.
No worries. The next version of Catalina will not require you to use make for anything, and will therefore not need MinGW/MSYS installed at all just to build any of the demos or utilities. In fact, I'm hoping to eventually make it so that you never need to leave Code::Blocks at all - i.e. no command line (unless you want to use it, of course).
This will be one of the differentiators between Catalina and GCC. The goal is to make Catalina so easy to install and use that it becomes the equivalent of the "Propeller Tool" for C programmers.
The goal is to make Catalina so easy to install and use that it becomes the equivalent of the "Propeller Tool" for C programmers.
I think that would be true now. The way the instruction manual pops up as part of the install means it is pretty easy.
I'm still working on making the hardware side just as easy. I've just designed some more Gadget Gangster boards and am getting some various parts together.
A technical question: When I wrote some of the "cogject" loadable cog code, I compiled the pasm code separately and then pasted in the hex code as an array declaration in C. Somewhere earlier (in this thread or one of the other C threads) someone posted a line of C code that allowed inline assembly. Would it be possible to add inline assembly code to catalina? I know it would be somewhat complex, because you would need to isolate the pasm code, compile it separately, and then paste it back into the program (presumably as an array of data). I did write something in vb.net to do this. Not impossible. Is it worth thinking about? Or is there a better way to write pasm code?
A technical question: When I wrote some of the "cogject" loadable cog code, I compiled the pasm code separately and then pasted in the hex code as an array declaration in C. Somewhere earlier (in this thread or one of the other C threads) someone posted a line of C code that allowed inline assembly. Would it be possible to add inline assembly code to catalina? I know it would be somewhat complex, because you would need to isolate the pasm code, compile it separately, and then paste it back into the program (presumably as an array of data). I did write something in vb.net to do this. Not impossible. Is it worth thinking about? Or is there a better way to write pasm code?
I keep thinking about this one. It is not actually very difficult - my problem is that inline assembly is too easily abused - one line of assembly makes an entire C program unportable - potentially, even unportable between the P1 and the P2.
My preferred method is to write PASM functions, which are callable from C - that way, it is perfectly obvious which parts of the program are platform-specific assembler and which parts are C. Catalina already supports this.
Also, inline assembly is not part of the ANSI standard, and I would prefer to avoid non-ANSI extensions. Look at the mess that many compilers make of simple C programs because of all the non-standard extensions they encourage you to use. Often this is done to "lock" your code into a particular compiler. But since Catalina is "free" I have no interest in playing such dirty tricks on users.
If users want to start with Catalina but some eventually decide they want to migrate to GCC, then that's fine with me. Of course, it won't always be possible to go the other way, but there's nothing I can do about that.
Yes, you are right, there is a good reason for keeping the C as a standard that is portable.
Looking at Catalina, I think the way you do things is to add various hardware and software options in the command line rather than in the code. I partially wrote the cogjects to experiment with a way of adding new options, but in an ideal world these would all become part of the Catalina command line options.
Ok, recently Baggers released a really nifty video driver with 256x96 pixels. Let's say I wanted to add this to catalina. Mostly it is pasm, and it interacts in the 'standard' way, ie a contiguous list of longs with the address of the first long passed on cog startup. There is virtually no supporting spin code so this should be fairly easy to add in that changing a pixel is a matter of writing a byte value to @screen + n.
But let's say this is added to catalina, and I want to experiment and change the pasm code. For simplicity's sake, the parameter list stays the same. All that is changing is the pasm code.
In Spin/Pasm, this sort of exercise would be done in the prop tool.
Is this a matter of adding an 'include' line, then working out which file this adds, and then editing this file?
This is one area I have very mixed feelings. On one hand, I do completely buy the idea of portability, but there are boundary conditions. Video drivers are one sort of thing, and the counter tricks are another. One nice thing about C is a nice PASM program can be written using C for control structures and such. It's a nice combo, and it's easily abused for sure, but then again, what isn't that really works?
Thinking about the UNIX way, I come to the core point where the ability to do really powerful things also means being able to do really bad things. In-line assembly is one of those, where moderate use of it, or the control structure model makes a lot of sense. Then somebody will stuff some odd manipulation in there that's hard to sort out, no comments, just this little blob in the middle of what is otherwise a fine program. Edit: PASM encourages some "bad" things anyway, like self-modify code being the norm, rather than the exception.
I had a experience with this a while back. On the old Atari machine, a guy near where I live wrote a fairly nice BASIC compiler for the thing. Frankly, it's brilliant, executing the language in a very minimal space (128 bytes of system RAM, 4K banks of ROM), with real-time performance, suitable for dynamically drawn games, typical of that console. (It has no frame buffer, and the CPU literally deals with the display on the fly.)
So, I'm writing along, knocking out a game for the mini-game compo, and reach a point where I've really got to optimize some. There are a few things that a few well placed CPU instructions will sort out nicely, with the compiled result being far less than optimal. Yeah, I in-lined it, commenting the few instructions, and it's great! True, there is exactly ONE target, but it's still great, because it's very lean, allowing one to fixate on one specific task in assembly without having to manage a lot of other stuff. The savings can be significant, as can be the mess!
Edit: This also has the nice advantage of writing some PASM within a nice framework, again allowing somebody to literally understand and write a few instructions to great effect. I personally really like that, even if it can be abused. So can the blobs!
Now, that environment has a great process, where the source code is broken down into intermediate files, each with sensible labels, so my in-line can actually refer to things like variable names and such in a way that's rather clear. Some well designed COG C could work in very similar ways. Not sure in-line makes sense for LMM, but it sure does in the COG, as not having it leaves us either doing it all in C, or... loading up blobs, or writing some very thick code in C, as you've demonstrated already as the "portable" work around for in-line.
Is there a split the middle choice here?
On one hand, the C is pure, but on the other, I've got two distinct modes to manage the blob. There is the tool that the blob was authored in, such as some assembler, or the Prop Tool, BST, etc... and there is the C program. In-line means ONE mode, and that's worth something. To me, worth a lot actually. Others?? Don't know. Thought I would chime in.
Portability between P1 and P2 is going to happen for a lot of cases, non boundary cases mostly, where the requirements are such that PASM won't make a significant difference. For other cases though, and I can easily see video related things being exactly these cases, the P1 code stream is either going to be included, or interleaved with the P2 stream, whichever makes sense. (I would include before mixing them together, but that's me, and I know others would probably just #ifdef the thing, and either is fine)
Finally, I can read C as control structure + PASM easily! It's not a bad way to go, particularly if some nice conventions for registers and such are employed. In some ways, it might be simpler than just a PASM driver written densely. For those, it's gonna have to be a blob, just because of how PASM is. No worries, but a whole lot of things don't have to be, yet probably won't quite be optimal in C.
Edit: On P1, this is true for the speed the chip runs at, and the stuff we regularly do on it. For P2, there are lots of little complexities that may well be more simply expressed in PASM, or at the least, best exploited that way, meaning blobs would be frequent. Are those better overall?
Another edit: Since the chip has some specialized instructions, and on-board silicon goodies, isn't there a case for in-line, because really exploiting those things isn't really portable anyway? Seriously. A more "pure" CPU, sans those things, really doesn't have the same cases, though many of the points I made above still apply.
Ok, recently Baggers released a really nifty video driver with 256x96 pixels. Let's say I wanted to add this to catalina. Mostly it is pasm, and it interacts in the 'standard' way, ie a contiguous list of longs with the address of the first long passed on cog startup. There is virtually no supporting spin code so this should be fairly easy to add in that changing a pixel is a matter of writing a byte value to @screen + n.
But let's say this is added to catalina, and I want to experiment and change the pasm code. For simplicity's sake, the parameter list stays the same. All that is changing is the pasm code.
In Spin/Pasm, this sort of exercise would be done in the prop tool.
Is this a matter of adding an 'include' line, then working out which file this adds, and then editing this file?
Hi Dr_A,
With Catalina there are at least three ways of going about this - all are documented, with examples provided:
You can wrap the driver in a spin program and use the spinc program to compile it. For an example of this, see the demos\spinc\kb_tv.spin file (the spin program that wraps an existing TV driver and keyboard) and the file demos\spinc\run_kb_tv.c (the C program that uses it). This has the advantage of generality - i.e. the C program can use any function provided by the Spin driver. It requires no change to the existing driver, and the spin wrapper is quite simple to write - but it is a little difficult to interact between C and Spin.
You can wrap the driver in a C program that "registers" the spin drivers and use the spinc program to compile it. For an example of this, see the demos\spinc\hmi.spin file (the spin program that registers an existing TV driver and keyboard) and the file demos\spince\run_tiny_hmi.c (the C program that uses it). This is slightly more complex than option 1, but there is still no change to the existing spin driver, and it is much simpler to interact between C and Spin since you can often use the standard C library functions.
You can convert the PASM part of the driver to a plugin. This offers the smallest code size and best performance, but is slightly more complex. For an example, see the file target\Catalina_GamePad.spin - this file leaves the original code in place (but comments it out), so you can easily see what needed to be changed to convert a spin/PASM driver to a plugin.
Yep, a Proptool for C programmers, Clusso or Drac might like to produce a CatBlade (a Ramblade with a 1024K EEPROM). Then all that would be needed is a script to load the binaries directly from CODE:BLOCKS. A new resident loader in the first 32k of the EEPROM could then load the binaries directly from the serial port to EEPROM above 32K. Just a thought.
If you think that it can be done I could change the EEPROM on my Ramblade
Hi, I finally took the time to install the ver 3.1. Installed like a champ no problems Great work Ross!!
Just for the heck of it I downloaded a C program from Sparkfun for their Nokia knock off LCD. It compiled just fine with Catalina. I know it would need modification to run on the Prop. May be a project for the winter!
I was using the Proptool today and noticed how often I use Help and pull up the propeller manual (both the quick reference and the full manual). I was wondering if it is possible to customise Code::blocks so you can add your Catalina pdf manuals to the Help menu?
I was using the Proptool today and noticed how often I use Help and pull up the propeller manual (both the quick reference and the full manual). I was wondering if it is possible to customise Code::blocks so you can add your Catalina pdf manuals to the Help menu?
Godd idea, Dr_A! I'll look into it for the next release. I should at least add appropriate links to the start menu.
With Catalina there are at least three ways of going about this - all are documented, with examples provided:
You can wrap the driver in a spin program and use the spinc program to compile it. For an example of this, see the demos\spinc\kb_tv.spin file (the spin program that wraps an existing TV driver and keyboard) and the file demos\spinc\run_kb_tv.c (the C program that uses it). This has the advantage of generality - i.e. the C program can use any function provided by the Spin driver. It requires no change to the existing driver, and the spin wrapper is quite simple to write - but it is a little difficult to interact between C and Spin.
You can wrap the driver in a C program that "registers" the spin drivers and use the spinc program to compile it. For an example of this, see the demos\spinc\hmi.spin file (the spin program that registers an existing TV driver and keyboard) and the file demos\spince\run_tiny_hmi.c (the C program that uses it). This is slightly more complex than option 1, but there is still no change to the existing spin driver, and it is much simpler to interact between C and Spin since you can often use the standard C library functions.
You can convert the PASM part of the driver to a plugin. This offers the smallest code size and best performance, but is slightly more complex. For an example, see the file target\Catalina_GamePad.spin - this file leaves the original code in place (but comments it out), so you can easily see what needed to be changed to convert a spin/PASM driver to a plugin.
Ross.
I wonder if there is another way that has become available recently?
I've been playing around with the Spin2cpp program and it appears to have a 'compile to C' option. I haven't tested it to breaking point but it looks like standard C.
So I ran a small Spin plus Pasm program through the Spin2cpp program and it produced C with all the pasm part as hex. It could be a simpler way to convert any obex program into something that catalina can use.
I wonder if there is another way that has become available recently?
I've been playing around with the Spin2cpp program and it appears to have a 'compile to C' option. I haven't tested it to breaking point but it looks like standard C.
So I ran a small Spin plus Pasm program through the Spin2cpp program and it produced C with all the pasm part as hex. It could be a simpler way to convert any obex program into something that catalina can use.
Your thoughts would be most appreciated.
I've only played very briefly with the more recent versions of Spin2cpp, but I seem to recall it can emit ANSI C. I tend to write my own C access functions, since doing this translation manually only takes a few minutes (the access methods tend to be quite trivial) - but maybe Spin2cpp could help.
Comments
I was pondering this last night, and I wonder if one very simple change to the install process could solve all the problems I had and make it easier for a beginner. In the install process a number of screens come up in sequence. I wonder if you could add one more that simply says "View Readme now" or "View documentation now" and a little check box?
Default is the box is checked, and if it is checked, it opens up the getting started document.
And fairly early on in the document, some screenshots or whatever about how to set it up for your particular hardware (C3, gadget gangster, hydra or whatever).
Specifying the HMI options you would like supported on a particular platform is now simpler in Catalina 3.1.
Attached is a replacement DracBlade_HMI.inc that enables the TV drivers on the DracBlade. The default driver is still the VGA driver, so to actually use the TV drivers you must specify either -D TV, -D HIRES_TV or -D LORES_TV on the command line (or select the appropriate check box in Code::Blocks).
This file also disables the mouse driver, so you don't need to specify -D NO_MOUSE on each compile.
To modify the pins assigned to the TV output, you edit the file DracBlade_DEF.inc (also in the target folder). I have attached a version that uses pins 17, 18, 19 (as per your request).
Just copy the attached files over the existing files in the target folder.
Let me know if you have any problems.
Ross.
As per Dr_Acula's suggestions, I have updated the new Catalina 3.1 Windows installer (on SourceForge) so that it now displays a new CodeBlocks QuickStart guide on completion of the install (assuming you chose to install Code::Blocks).
The Quickstart guides you through starting Code::Blocks for the first time, and then creating, compiling and downloading your first "hello world" type C application.
This guide contains a subset of the informationin Getting Started with CodeBlocks, but hopefully doing it this way means some users may actually read it!
Ross.
1) Go to post #30 on this thread, and click the link at the top of that post. The download starts automatically.
2) Answer the questions. The Help manual opens automatically (Thanks++ Ross for adding that feature)
3) Follow the instructions.
There are two things I wanted to check out
1) Changing all the text highlighting colors and options. (settings/editor and on the left four down, syntax highlighting) This can be done in code::blocks, so if you don't like the color purple, change it to something else. Nifty!
2) A problem I was getting with a huge C program is finding my way around the program. But in code:blocks there are little minus signs that appear for each block of code, and you can shrink these blocks down. This means that once a function is working you can hide it. (I think this is called 'folding')
IMHO this is extremely useful. It means you can really concentrate on a few functions that might be interacting with each other (probably the Main and a sub function) and have them on the same screen.
This is really going to speed up development. And I really appreciate this feature because I tried for some months to find a way to code it in vb.net in my IDE and never really found a satisfactory solution (ditto syntax highlighting, which I got working but only slowly). So I am very pleased to see these features in code::blocks.
I tried finding the link on sourceforge to the 'setup' single click link but I couldn't find it. I was wondering, since this is such a quantum leap in terms of ease of use, whether the contents of post #30 on this thread might warrant being replicated on post #1 of a new thread, so we (ok, me) can find it in future if I forget that it is hidden inside this thread?
Cheers, (and thanks++ again to Ross for making this happen)
I think I found a minor bug. When compiling the next simple program I get an overflow warning.
#include <stdio.h> #include "float.h" int main(int argc, char *argv[]) { float f_max; f_max = FLT_MAX; while(1) ; return 0; }Thankyou, Juan Carlos.
Yes, I knew about this one. From memory, the FLT_MAX constant defined in float.h is actually a 64 bit value, whereas Catalina floats are 32 bits. I think it works just as well, since you end up with the equivalent 32 bit FLT_MAX value - but it does throw a compiler warning. I left the 64 bit value in there since I was (at one stage) considering supporting 64 bit floating point - but there doesn't seem to be much call for 64 bit floating point on the Propeller , so I should really fix it. Thanks for reminding me.
Ross.
FLT_MAX on *nix is 32 bits, DBL_MAX is 64 bits, e.g. from IRIX:
limits.h:232:#define FLT_MAX 3.40282347E+38F /* max decimal value of a "float" */
limits.h:228:#define DBL_MAX 1.7976931348623157E+308 /* max decimal value of a "double"*/
-Tor
Hi Tor,
I don't believe the C standard specifies that floats have to be 32 bits and doubles 64 bits. It is quite acceptable for both to be 32 (as in Catalina) or both to be 64 bits. In fact, the size is not specified in bits at all - the standard just specifies the range and precision that must be able to be represented.
In any case, the problem is not quite what I remembered (although, it is true that Catalina generates the correct value internally, despite throwing the overflow warning - I remember testing that!). I had remembered to use a FLT_MAX value appropriate to 32 bit floats, but I made the same mistake your IRIX include files made - i.e. both the Catalina and the IRIX values are in fact incorrect, and this shows up if the compiler is run on a machine which itself has 32 bit floats!
The correct value for an IEEE754 32 bit FLT_MAX (when using extended precision) is actually 3.4028234663852886E+38. Rounding that value up to 3.40282347E+38 is what is causing the overflow warning - even though it generates (bit for bit) the correct 32 bit internal representation!
You would probably not get the warning at all on a maching that used 64 bit representations of all floating point values during compilation - this is probably why the incorrect value works on IRIX.
For the moment, Catalina will throw the overflow warning (but generate the correct value!) if FLT_MAX is used. I willl fix this in the next release.
Ross.
It's correct that ANSI C only specifies a minimum precision for each type, but IEEE 754 specifies single precision and double precision as 32- and 64 bit respectively, and any architecture compatible with IEEE 754 will thus in practice have to use a 32-bit "float" type and a 64-bit "double" type. I don't think I've seen anything reasonably modern that doesn't use 32 bits for float and 64 bits for double, not even for architectures which are not IEEE 754 compatible.
Tru64 (DEC) also uses the same definition as IRIX. AIX uses the longer value you listed, and Solaris uses an even longer one (3.4028234663852885981170E+38F).
I'm not sure about that - the 'F' at the end is supposed to tell the compiler that the value shall be handled as single precision all the way, presumably also during compilation. In any case none of the architectures listed will give a warning. This is of course mostly a technicality though.
-Tor
It is true that if you are using IEEE754 then your only choices of sizes are 32 or 64 bit - but that doesn't mean a C compiler has to choose 32 bit as float size and 64 bit as a double. A float can be 64 bit, or a double can be 32 bit. (although I think there is probably a requirement that a float be able to be converted to a double and back again without losing precision, which means the available choices for float/double sizes are 32/32, 64/64 or 32/64 - but not 64/32).
Now you are really getting into the innards - but it's quite interesting
To understand the meaning of the "F" at the end of such a high precision constant, consider it this way: if your compiler processes floating point constants as 32 bits during parsing then it cannot even successfully represent a declaration such as 3.4028234663852885981170E+38F - the 32 bit float would overflow as soon as it got beyond about the 10th digit. But a compiler can internally represent such constants as 64 bit values, treating the F as meaning that they should be truncated to 32 bit values after parsing (or perhaps even later - during the actual code generation). Then everything works as you see on Tru64, Solaris and IRIX.
There are also other ways of coping with this problem, but I believe the latter is how many C compilers actually work - i.e.all floating point constants are represented internally during code parsing and generation to the maximum machine representation (which is typically 64 bits). In such cases, all the definitions of FLT_MAX we have been discussing will work. The problem we see with Catalina arises only if the compiler tries to represent all 32 bit constants internally as 32 bits. In that case, all the definitions of FLT_MAX we have been discussing will in fact overflow during compile.
Ross.
-Tor
I have been avoiding the upgrade, because I had gotten very comfortable with Catalina 2.9 and CodeBlocks. Thankyou for the BETA_Catalina_3.1_Setup. It workes like a Charm !
I do have a problem with the Catalyst install though. When I run the following, build_all RAMBLADE PC VT100 ,from the Catalyst folder, I get and error "MSYS not in the current path !!"
I have used Catalyst with Catalina 2.9, that's history now.
I have read your notes re- issues with MSYS and windoze 7 and taken them onboard, but at this stage I have not been able to build a Catalyst.binary file.
Any thoughts ?
Ron
Hi Ron,
Building the Catalyst demos requires make (Catalyst itself does not, but some of the demos do). If I cannot find the 'make' executable then I print that error. I'm not sure what version of MinGW/MSYS you have, but I do recall that in some versions the installation of MinGW 'make' was an optional component and you had to select it during install. Please ensure you have it installed, and that both the MinGW and MSYS 'bin' directories are in your current path.
Ross.
I had downloaded a new version of MinGW and didn't reset the path to the new location
Problem fixed.
Thanks again.
Ron
Hi Ron.
No worries. The next version of Catalina will not require you to use make for anything, and will therefore not need MinGW/MSYS installed at all just to build any of the demos or utilities. In fact, I'm hoping to eventually make it so that you never need to leave Code::Blocks at all - i.e. no command line (unless you want to use it, of course).
This will be one of the differentiators between Catalina and GCC. The goal is to make Catalina so easy to install and use that it becomes the equivalent of the "Propeller Tool" for C programmers.
Ross.
I think that would be true now. The way the instruction manual pops up as part of the install means it is pretty easy.
I'm still working on making the hardware side just as easy. I've just designed some more Gadget Gangster boards and am getting some various parts together.
A technical question: When I wrote some of the "cogject" loadable cog code, I compiled the pasm code separately and then pasted in the hex code as an array declaration in C. Somewhere earlier (in this thread or one of the other C threads) someone posted a line of C code that allowed inline assembly. Would it be possible to add inline assembly code to catalina? I know it would be somewhat complex, because you would need to isolate the pasm code, compile it separately, and then paste it back into the program (presumably as an array of data). I did write something in vb.net to do this. Not impossible. Is it worth thinking about? Or is there a better way to write pasm code?
I keep thinking about this one. It is not actually very difficult - my problem is that inline assembly is too easily abused - one line of assembly makes an entire C program unportable - potentially, even unportable between the P1 and the P2.
My preferred method is to write PASM functions, which are callable from C - that way, it is perfectly obvious which parts of the program are platform-specific assembler and which parts are C. Catalina already supports this.
Also, inline assembly is not part of the ANSI standard, and I would prefer to avoid non-ANSI extensions. Look at the mess that many compilers make of simple C programs because of all the non-standard extensions they encourage you to use. Often this is done to "lock" your code into a particular compiler. But since Catalina is "free" I have no interest in playing such dirty tricks on users.
If users want to start with Catalina but some eventually decide they want to migrate to GCC, then that's fine with me. Of course, it won't always be possible to go the other way, but there's nothing I can do about that.
Ross.
Yes, you are right, there is a good reason for keeping the C as a standard that is portable.
Looking at Catalina, I think the way you do things is to add various hardware and software options in the command line rather than in the code. I partially wrote the cogjects to experiment with a way of adding new options, but in an ideal world these would all become part of the Catalina command line options.
Ok, recently Baggers released a really nifty video driver with 256x96 pixels. Let's say I wanted to add this to catalina. Mostly it is pasm, and it interacts in the 'standard' way, ie a contiguous list of longs with the address of the first long passed on cog startup. There is virtually no supporting spin code so this should be fairly easy to add in that changing a pixel is a matter of writing a byte value to @screen + n.
But let's say this is added to catalina, and I want to experiment and change the pasm code. For simplicity's sake, the parameter list stays the same. All that is changing is the pasm code.
In Spin/Pasm, this sort of exercise would be done in the prop tool.
Is this a matter of adding an 'include' line, then working out which file this adds, and then editing this file?
This is one area I have very mixed feelings. On one hand, I do completely buy the idea of portability, but there are boundary conditions. Video drivers are one sort of thing, and the counter tricks are another. One nice thing about C is a nice PASM program can be written using C for control structures and such. It's a nice combo, and it's easily abused for sure, but then again, what isn't that really works?
Thinking about the UNIX way, I come to the core point where the ability to do really powerful things also means being able to do really bad things. In-line assembly is one of those, where moderate use of it, or the control structure model makes a lot of sense. Then somebody will stuff some odd manipulation in there that's hard to sort out, no comments, just this little blob in the middle of what is otherwise a fine program. Edit: PASM encourages some "bad" things anyway, like self-modify code being the norm, rather than the exception.
I had a experience with this a while back. On the old Atari machine, a guy near where I live wrote a fairly nice BASIC compiler for the thing. Frankly, it's brilliant, executing the language in a very minimal space (128 bytes of system RAM, 4K banks of ROM), with real-time performance, suitable for dynamically drawn games, typical of that console. (It has no frame buffer, and the CPU literally deals with the display on the fly.)
So, I'm writing along, knocking out a game for the mini-game compo, and reach a point where I've really got to optimize some. There are a few things that a few well placed CPU instructions will sort out nicely, with the compiled result being far less than optimal. Yeah, I in-lined it, commenting the few instructions, and it's great! True, there is exactly ONE target, but it's still great, because it's very lean, allowing one to fixate on one specific task in assembly without having to manage a lot of other stuff. The savings can be significant, as can be the mess!
Edit: This also has the nice advantage of writing some PASM within a nice framework, again allowing somebody to literally understand and write a few instructions to great effect. I personally really like that, even if it can be abused. So can the blobs!
Now, that environment has a great process, where the source code is broken down into intermediate files, each with sensible labels, so my in-line can actually refer to things like variable names and such in a way that's rather clear. Some well designed COG C could work in very similar ways. Not sure in-line makes sense for LMM, but it sure does in the COG, as not having it leaves us either doing it all in C, or... loading up blobs, or writing some very thick code in C, as you've demonstrated already as the "portable" work around for in-line.
Is there a split the middle choice here?
On one hand, the C is pure, but on the other, I've got two distinct modes to manage the blob. There is the tool that the blob was authored in, such as some assembler, or the Prop Tool, BST, etc... and there is the C program. In-line means ONE mode, and that's worth something. To me, worth a lot actually. Others?? Don't know. Thought I would chime in.
Portability between P1 and P2 is going to happen for a lot of cases, non boundary cases mostly, where the requirements are such that PASM won't make a significant difference. For other cases though, and I can easily see video related things being exactly these cases, the P1 code stream is either going to be included, or interleaved with the P2 stream, whichever makes sense. (I would include before mixing them together, but that's me, and I know others would probably just #ifdef the thing, and either is fine)
Finally, I can read C as control structure + PASM easily! It's not a bad way to go, particularly if some nice conventions for registers and such are employed. In some ways, it might be simpler than just a PASM driver written densely. For those, it's gonna have to be a blob, just because of how PASM is. No worries, but a whole lot of things don't have to be, yet probably won't quite be optimal in C.
Edit: On P1, this is true for the speed the chip runs at, and the stuff we regularly do on it. For P2, there are lots of little complexities that may well be more simply expressed in PASM, or at the least, best exploited that way, meaning blobs would be frequent. Are those better overall?
Another edit: Since the chip has some specialized instructions, and on-board silicon goodies, isn't there a case for in-line, because really exploiting those things isn't really portable anyway? Seriously. A more "pure" CPU, sans those things, really doesn't have the same cases, though many of the points I made above still apply.
Hi Dr_A,
With Catalina there are at least three ways of going about this - all are documented, with examples provided:
- You can wrap the driver in a spin program and use the spinc program to compile it. For an example of this, see the demos\spinc\kb_tv.spin file (the spin program that wraps an existing TV driver and keyboard) and the file demos\spinc\run_kb_tv.c (the C program that uses it). This has the advantage of generality - i.e. the C program can use any function provided by the Spin driver. It requires no change to the existing driver, and the spin wrapper is quite simple to write - but it is a little difficult to interact between C and Spin.
- You can wrap the driver in a C program that "registers" the spin drivers and use the spinc program to compile it. For an example of this, see the demos\spinc\hmi.spin file (the spin program that registers an existing TV driver and keyboard) and the file demos\spince\run_tiny_hmi.c (the C program that uses it). This is slightly more complex than option 1, but there is still no change to the existing spin driver, and it is much simpler to interact between C and Spin since you can often use the standard C library functions.
- You can convert the PASM part of the driver to a plugin. This offers the smallest code size and best performance, but is slightly more complex. For an example, see the file target\Catalina_GamePad.spin - this file leaves the original code in place (but comments it out), so you can easily see what needed to be changed to convert a spin/PASM driver to a plugin.
Ross.What GCC?
It's still in the horse box!
Yep, a Proptool for C programmers, Clusso or Drac might like to produce a CatBlade (a Ramblade with a 1024K EEPROM). Then all that would be needed is a script to load the binaries directly from CODE:BLOCKS. A new resident loader in the first 32k of the EEPROM could then load the binaries directly from the serial port to EEPROM above 32K. Just a thought.
If you think that it can be done I could change the EEPROM on my Ramblade
Keep up the good work
Ron
Just for the heck of it I downloaded a C program from Sparkfun for their Nokia knock off LCD. It compiled just fine with Catalina. I know it would need modification to run on the Prop. May be a project for the winter!
I was using the Proptool today and noticed how often I use Help and pull up the propeller manual (both the quick reference and the full manual). I was wondering if it is possible to customise Code::blocks so you can add your Catalina pdf manuals to the Help menu?
Godd idea, Dr_A! I'll look into it for the next release. I should at least add appropriate links to the start menu.
Ross.
Sorry to resurrect an old thread! Re post #81
I wonder if there is another way that has become available recently?
I've been playing around with the Spin2cpp program and it appears to have a 'compile to C' option. I haven't tested it to breaking point but it looks like standard C.
So I ran a small Spin plus Pasm program through the Spin2cpp program and it produced C with all the pasm part as hex. It could be a simpler way to convert any obex program into something that catalina can use.
Your thoughts would be most appreciated.
I've only played very briefly with the more recent versions of Spin2cpp, but I seem to recall it can emit ANSI C. I tend to write my own C access functions, since doing this translation manually only takes a few minutes (the access methods tend to be quite trivial) - but maybe Spin2cpp could help.
When I get time I'll look into it further.
Ross.