So the loader is 64K? Is that necessary? That + 32K minimum app code puts most hardware out of business.
Good thing I have an eeprom DIP socket on one of my boards.
What I want to see eventually is a loader or O/S that can launch an xmm binary from uSD card.
An intermediate step is to have a loader that can download/start a hex image from serial or uSD.
This intermediate step is useful so that *any* Propeller regardless of eeprom size with XMM hardware can be used.
Is there any way to make the loader fit in Propeller hub ram or 32K eeprom?
jazzed said...
Is there any way to make the loader fit in Propeller hub ram or 32K eeprom?
Yes - just use LMM mode. To summarize:
- If you need your program AND your target (i.e. your plugins and drivers) to fit completely within 32k you compile it as an LMM program (the default).
- If your program needs have the whole 32k to itself (and you have a 64k+ EEPROM) then you compile it as an EMM program.
- If your program needs more than 32k then you compile it as an XMM program.
LMM programs are simple - everything is compiled together into 32k just like any other Propeller program.
For EMM and XMM the loader+target is (max) 32k. These are compiled into a 32k image even if they only take 1k. The application program is then compiled into a separate image. For EMM this is always 32k. For XMM this defaults to 64k but can be smaller or larger. Then the two images are simply concatenated.
The reason for this is that the EMM and XMM loaders need to know where to find the application program (i.e. at $8000) in the EEPROM. If you limited yourself to smaller loaders (you may theoretically need up to 2k*8 = 16k of PASM + some SPIN "glue" - say 24k max) - you could start the application code at $6000 and fit another 8k of program code in the EEPROM. This didn't seem worthwhile to me when I already had XMM - it would just complicate thinge further (!). But it is a trivial mod to make if you want to do it.
I also would like to be able to load from SD card. Previously I didn't have suitable hardware. I do now, so that's on my list - along with file system support from C.
I agree loading over serial would be a nice intermediate step - it would be fairly easy to do - but I couldn't see any practical application for it.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
A "loader" loads another program to run. In this case, an XMM program (the "loadee"?) is the thing to be loaded by the "loader" and could be of any reasonable size. The "loader" should be under 32K. What and where is the "loader" source? What's the best way to build just a "loader" and what size would it be?
Why do I not get to see the sources being used on an emm/xmm build like in an lmm build?
I'm not used to an opaque build process.
A practical application of serial load is mainly ease of use. Not all my eeproms are big enough for your images which should be vividly pretty obvious by now.
Yes, we don't appear to be communicating very well, do we I agree that it seems to be a terminology problem. Let me start again ...
The loader you seem to be looking for is a general purpose utility that can load a compiled Catalina program from somewhere off-chip (e.g. from a serial port, an SD card or an EEPROM) into a location from which it can be executed (either HUB RAM or XMM RAM) - and then set it executing. Is that correct? If so, I'm afraid there is simply no such beast - at least not yet.
As I mentioned in an earlier post, I hope to have an SD Card loader soon. That will probably be a little more like what you want. However, if you want to develop a serial loader in the meantime, you can just take one of the existing loaders (start with the XMM EEPROM loader) and modify it for your own use. If you like, I'd be more than happy to include the result in the Catalina source tree.
By the way, the Hydra Asset Manager has a loader that does something along the lines of what you want - i.e. you first load the loader (using another loader of course) and it then accepts a program sent serially. It then programs the Hydra EEPROMs with the result, whereas you presumably want to load XMM with the result - but that's the trouble with such loaders: i.e. you typically need a different one for each platform you want to load to.
I don't presently need such a general purpose loader. Instead, I have a separate target for each possible platform (to take into account the device and pin differences) and also a separate 'low level' loader - and there will be one of those for each possible combination of source (i.e. EEPROM, SD Card, Serial) and destination (i.e. HUB RAM or XMM RAM).
Using Catalina terminology, there are three main components required to get a program executing:
The 'target' - this sets up all the device drivers and other plugins (e.g. real-time clock, floating point co-processor) that comprise the environment that the application code needs to execute.
The 'loader' - this loads the application code into the correct place (or places) for execution - and then loads and starts the kernel.
The 'program' or 'application code' - this is the compiled version of your C program.
So the type of loader I am talking about is probably a much lower level beast than the type of loader you are looking for.
Typically, for LMM programs the target, loader and program are all compiled into one executable file. In practice, LMM programs don't need much a loader, since they are executed 'in place' in hub RAM - so the only job of the loader is to load and start the kernel.
But for EMM and XMM the target and loader are compiled together into one file (which is saved as a 32kb EERPROM image) which then sits around in the target directory until you have some application code that needs to use it - which is compiled into another file. This is why the EMM and XMM compile process appears to be 'opaque' - it isn't, but it may seem to be because it only compiles the C application code each time, whereas the LMM compile process compiles everything each time. If you want to see the rest of the EMM and XMM compile process, go to the target directory and enter 'build_targets' - but you don't usually need to do this unless you specifically want to change something in a target or in the Catalina_Common.spin file.
So ... getting back to the loader(s) ... at least in the Catalina meaning of the term ...
The EMM Loader is in the target directory. It is called Catalina_EMM_EEPROM_Loader.spin. As the name implies, it can only load from EEPROM, and it always loads into hub RAM. It always loads from address $8000 in the EEPROM.
The XMM Loader is also in the target directory. It is called Catalina_XMM_EEPROM_Loader.spin. Again, it can only load from EEPROM (and again, from address $8000) - but it loads into XMM RAM - and it currently only supports the Hydra Xtreme.
Hope this helps,
Ross.
EDIT: forgot to say - you should discard all the files from previous releases - e.g. the previous 'xmm_hires.spin' doesn't use the new 'Catalina_Common.spin' file.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
It is clear there is no "loader" beast. I fully expect to write code I need. If I knew the parts available, I could put it together myself. I've seen Catalina_XMM_EEPROM_Loader.spin and tried to use it ... for some reason it stays stuck reading from eeprom and it's not obvious why that happens.
Is the loader that you have really 32KB or is that just a 0 padded eeprom file?
Your intel-hex files contain many unnecessary 0 data lines ... how can they be removed?
jazzed said...
I've seen Catalina_XMM_EEPROM_Loader.spin and tried to use it ... for some reason it stays stuck reading from eeprom and it's not obvious why that happens.
It sounds like you're using all the right parts. This could be a problem with my I2C implementation. There was no PASM driver for I2C when I started so I wrote my own - but of course it's only been tested on the Hydra. However, I think I saw somewhere that there is now a pure PASM I2C driver, so you could try that.
jazzed said...
Is the loader that you have really 32KB or is that just a 0 padded eeprom file?
Yes, it's zero padded, and that 32k also includes all the drivers and plugins. The actual loader is pure PASM, so it is less than 2k.
jazzed said...
Your intel-hex files contain many unnecessary 0 data lines ... how can they be removed?
Generate a binary ouptut instead of an eeprom - even if you subsequently generate intel-hex format, this causes the zero records to be left off the end. But there will still be some zero records in the middle - to eliminate those you would have to use the appropriate srecord options.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
PropDos can load a standard binary from SD. So all we need for now is that binary to be a "loader" to load a Catalina binary.
I will be writing minimal code to boot a binary from SD. I need to fit this "boot code" into a MC9S08 which will boot the RamBlade when no secondary prop terminal is available. I am hoping that I may be able to fit it into under 4KB.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Ive finally managed to resolve an annoying problem with the Catalina code generator ... it is mentioned in the beta 4 release notes as follows:
Catalina.pdf said...
Complex expressions involving functions that return structures can cause the Catalina Code generator to fail (in such cases lcc will return an assertion failure). This is quite rare, and the workaround is to locate and simplify the offending expression - i.e. evaluate the expression in several steps instead of as one large expression
Turns out to be a simple fix, but finding it has caused me to lose a lot of time on XMM support, so I don't plan to issue a new release just yet. However, if you want to recompile Catalina from source, the fix is a one line change to the function "clobber" (in source/lcc/src/catalina.md):
static void clobber(Node p) {
assert(p);
switch (p->op) {
case CALL+F:
spill(INTTMP | INTRET, IREG, p);
spill(FLTTMP, FREG, p);
break;
case CALL+I: case CALL+P: case CALL+U:
spill(INTTMP, IREG, p);
spill(FLTTMP | FLTRET, FREG, p);
break;
case CALL+V:
spill(INTTMP, IREG, p); // don't clobber our own target <=== THIS LINE CHANGED
spill(FLTTMP | FLTRET, FREG, p);
break;
}
}
@Dale Stewart,
I promised (earlier in this thread) to report when my copy of the lcc book "A retargetable C compiler: Design and Implementation" arrived. Well it finally did - and while it did help me track down the abovementioned bug, I couldn't otherwise recommend it. It's almost unreadable. The big giveaway is on page 11 - despite the title, the authors acknowledge that there was no actual design phase for lcc. The book certainly shows evidence of this lack - it doesn't seem to follow any natural or logical order, or have any overall structure that I can discern. For example, by page 6 we're discussing abstract syntax notation trees, but basic language parsing is not covered in the main body of the book till page 100. Language declarations are not covered until page 250. The subject of the very first chapter (apart from the introduction) is ... wait for it ...memory allocation! The book is dated 1995, but it obviously has its roots deep in the 1970's when such things were "hot" research topics. While the content is undoubtedly still perfectly valid, starting the book this way just makes it seem very dated. And after starting out so badly, it fails to really improve much - it is very definitely a "bottom up" description of lcc. Perhaps the whole book is really intended to be read backwards.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I have probably a little strange question: How many assmbler instructions of the propellers instruction set does your compiler use? Does it need all? Would it be possible to reduce the instruction set to use a processor with the most important 16 instructions of the propeller?
In my opinion it is very bad idea.
For me it is same to buy " RoysRoys " and reconstruct is to " Fiat " for at I will have " Fiat "
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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.
First thing to do is to download Catalina and have a look in the lmm kernel module. All the instructions in there have to be working before any compiled C code will run.
Then perhaps Ross will tell you how many different PASM instructions can be generated by the compiler. Or again you can check the compilers code generator and count them yourself.
Anyway what you want seems unlikely to me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The code generator only currently generates about 30 different instructions - have a look in the file "source/lcc/src/catalina.md". But as heater says, the kernel will use a bunch more - have a look in the file "target/Catalina_LMM.spin"
However, I wouldn't guarantee that it will stay that way - I intend to go back and do more optimization over time, of both the Kernel and the Code Generator - so the instructions required may change.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
>Chris Micro: I see where you are going with this.
Hey, you are one step ahead of Sapieha.
I was thinking of simply making statistics of the code. But I thought it's easier to ask the expert directly. I simply want to spare work by not have to implement all instructions.
>The code generator only currently generates about 30 different instructions - have a look in the file "source/lcc/src/catalina.md". But >as heater says, the kernel will use a bunch more - have a look in the file "target/Catalina_LMM.spin"
Hi RossH,
Thank you for the answer. I will take a look at the *.md files.
You said " I was thinking of simply making statistics of the code ".
That statisticas of code used by C and ASM on Intel's 8080-8085 CPU give os bad posiblites in Intel 8088-8086 code.
Them optimized out instructions from 8080 ASM set that have ben used not frequently.
And it result in optimising out all CALL on flags instructions !!
Regards
Christoffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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: That's interesting. I seem to remember reading many years ago, when the 6809 was new, that Motorola had done a lot of statistical analysis of existing code in order to decide what instructions the new chip should have.
Result, the 6809 ended up with no conditional CALLS as well !!
I always wondered if they just grabbed a load of listings and counted the occurrence of each instruction or if they actually ran the code to see what really got used most.
Makes one appreciate the Propeller way of handling conditional execution.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Chris Micro: As far as I understand you have created an emulation of some of the Prop instructions in C that runs on an AVR.
I must strongly encourage you to continue and expand your effort to emulation of all the instructions. After all there is only 64 opcodes, I'm busy working through 256+ for the 6809 emulator.
Be sure to take care of instruction timing and self-modifying code.
The result could be a nice fast Cog emulator that could be run on Windows or Linux or where ever and the Propeller community would love you forever.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
>I must strongly encourage you to continue and expand your effort to emulation of all the instructions
Thank you for that. I'm not sure yet, because for me it was only a try how difficult it would be to write an emulator.
With the structure of the existing code I have now it is easy to extend it. But it seems a lot of work ... Hmm, probably I will do it ...
> The result could be a nice fast Cog emulator that could be run on Windows or Linux or where ever and the Propeller community >would love you forever
Yes, you got the bigger goal. It would be very easy to transform the code to any platform ...
I was just having some questions about the different cogs. do i run _coginit(par, addr, cog) with par as the function name? and addr just as a random empty int?
No, the _coginit is a low level function to start a PASM program - it doesn't work like the SPIN function (which can start another SPIN function in a new cog).
Have a look at pages 284/285 of the Propeller manual (version 1.1) - the parameters to the coginit C function (i.e. par, addr, cogid) map to the destination register of the coginit assembly language instruction in a fairly straightforward manner, as follows:
par = bits 31:18 (i.e. the parameter to pass to the cog after startup)
addr = bits 4:17 (i.e. the long address of the code to load into the cog)
cogid = bits 3:0 new flag + cogid (i.e. the id of the cog to start, plus the new flag)
The C function does the shifting and combining required to put these parameters in the right places, but you must supply addr as a LONG address (dividing the actual address by 4). It points to 512 longs that represent the code. The par parameter can be any value (up to 14 bits) but is most often the address of a data block that contains configuration data for the cog - in which case it must also be divided by 4 (the reason I don't do the division by 4 automatically is that the par parameter may just be a value, not an address)
The fact that the cogid parameter also incorporates the new flag means a cogid of 8 will result in any free cog being used.
Here is a (non-working!) example of how I expected it would be used ...
#include <catalina_cog.h>
#define COG 7
void main() {
long code[noparse][[/noparse]512] = {0x12345678, 0x12345678, 0};
long data[noparse][[/noparse]32] = {1, 2, 3, 4};
int result;
result = _coginit ((int)data>>2, (int)code>>2, COG);
}
However, while writing this post I just reviewed the code to check on the parameter mapping and noticed that the par parameter is not being passed correctly. I will issue a fix and generate a working example of how to use it later today.
Ross.
Edit: minor correction to code
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Yes, I agree my RTC implementation is pretty much a waste of a cog - I'll have a look at your code and see if I can find a way to use it instead.
I didn't worry too much about it because the Prop crystal is not really accurate enough to be an RTC anyway - my plugin is mainly intended as an example.
If you need accurate time, you would be better off adding an external RTC chip. There are several RTC chips with I2C interfaces that are very simple to integrate with - what I really should do for the next release of Catalina is include a general purpose I2C plugin that is accessible from C.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I've included a fixed 'coginit' function, and a demo program showing how to use it, in the file 'catalina_coginit_fix.zip' attached to the first post in this thread.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Infinity successfully compiled beta 3 under OSX using gcc. I incorporated a couple of minor changes into the beta 4 makefiles as a result of his experience, so I believe it should now compile "out of the box" - but I don't have a Mac so I can't guarantee this.
You will also need to install mono in order to run homespun (same as for Linux).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Is there a way of passing (command line) #defines values to Homespun? Or putting in a list of paths to search with -T?
I am not a fan of editing Catalina_Common.spin for different boards to define the pinouts. I figure a #define in any spin plug-ins would be really useful mechanism that would solve it.
An alternative would be to pick up Catalina_Common.spin (or similar) in a local directory, instead of from the common library directory, using a include path type mechanism. I quickly tried that, but I suspect the -T Catalina argument does not support it.
The spin mechanism of 'importing' constants is pretty frustrating. One of the reasons for me to try C instead.
I'm thinking of implementing an 'asm' function, but it's not part of the ANSI standard. So yes, you have to currently specify PASM instructions in hex. The easiest way at the moment to get the required hex is to use Homespun to compile the PASM, and use the Homespun -d option to produce a list file - then cut and paste the bytes from that file. Be careful about byte ordering - homespun prints each long as 4 bytes, so it may be easier to represent the data in Catalina as an array of bytes - or if you want to represent it as longs you need to reverse the order of the bytes in each long.
But there is another, even easier way - each target has a file called something like 'catalina_target.s' where you can simply insert PASM instructions or data. For example, the default target has one called ' catalina_default.s' - add your PASM program to this, making sure your main symbol is prefixed by "C_" and is all lower case and has no other underscores - e.g. "C_mycode". Then you can refer in your C program to the symbol as simply "mycode". The binder will initially complain that this symbol is undefined, so you need to use the '-f' option to the binder (or the '-Wl-f' option to lcc) to force the binder to continue even if it has undefined symbols (it finds it later in the binding process).
Making data globally accessible between cogs is up to you - if all your coginit functions use a common data pointer (i.e. one declared as a static in C), then yes - all cogs will see the same data. I use this trick a lot - ff you also need to pass individual data to each cog as well as shared data, then have each cog retrieve its own id and use this as an index into an array of cog-specific data.
@matb,
I don't think homespun accepts #defines on the command line. But using the -T switch to the binder (or -Wl-T to lcc) to specify an alternate target directory works for me.
For example, I'm currently working on a set of targets for the Hybrid. So I created a copy of the target directory, called it 'hybrid', and I now compile for the Hybrid by saying something like:
Comments
Good thing I have an eeprom DIP socket on one of my boards.
What I want to see eventually is a loader or O/S that can launch an xmm binary from uSD card.
An intermediate step is to have a loader that can download/start a hex image from serial or uSD.
This intermediate step is useful so that *any* Propeller regardless of eeprom size with XMM hardware can be used.
Is there any way to make the loader fit in Propeller hub ram or 32K eeprom?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Yes - just use LMM mode. To summarize:
- If you need your program AND your target (i.e. your plugins and drivers) to fit completely within 32k you compile it as an LMM program (the default).
- If your program needs have the whole 32k to itself (and you have a 64k+ EEPROM) then you compile it as an EMM program.
- If your program needs more than 32k then you compile it as an XMM program.
LMM programs are simple - everything is compiled together into 32k just like any other Propeller program.
For EMM and XMM the loader+target is (max) 32k. These are compiled into a 32k image even if they only take 1k. The application program is then compiled into a separate image. For EMM this is always 32k. For XMM this defaults to 64k but can be smaller or larger. Then the two images are simply concatenated.
The reason for this is that the EMM and XMM loaders need to know where to find the application program (i.e. at $8000) in the EEPROM. If you limited yourself to smaller loaders (you may theoretically need up to 2k*8 = 16k of PASM + some SPIN "glue" - say 24k max) - you could start the application code at $6000 and fit another 8k of program code in the EEPROM. This didn't seem worthwhile to me when I already had XMM - it would just complicate thinge further (!). But it is a trivial mod to make if you want to do it.
I also would like to be able to load from SD card. Previously I didn't have suitable hardware. I do now, so that's on my list - along with file system support from C.
I agree loading over serial would be a nice intermediate step - it would be fairly easy to do - but I couldn't see any practical application for it.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 6/15/2009 11:49:45 PM GMT
A "loader" loads another program to run. In this case, an XMM program (the "loadee"?) is the thing to be loaded by the "loader" and could be of any reasonable size. The "loader" should be under 32K. What and where is the "loader" source? What's the best way to build just a "loader" and what size would it be?
Why do I not get to see the sources being used on an emm/xmm build like in an lmm build?
I'm not used to an opaque build process.
Here is the version info.
A practical application of serial load is mainly ease of use. Not all my eeproms are big enough for your images which should be vividly pretty obvious by now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Post Edited (jazzed) : 6/16/2009 12:28:26 AM GMT
Yes, we don't appear to be communicating very well, do we
The loader you seem to be looking for is a general purpose utility that can load a compiled Catalina program from somewhere off-chip (e.g. from a serial port, an SD card or an EEPROM) into a location from which it can be executed (either HUB RAM or XMM RAM) - and then set it executing. Is that correct? If so, I'm afraid there is simply no such beast - at least not yet.
As I mentioned in an earlier post, I hope to have an SD Card loader soon. That will probably be a little more like what you want. However, if you want to develop a serial loader in the meantime, you can just take one of the existing loaders (start with the XMM EEPROM loader) and modify it for your own use. If you like, I'd be more than happy to include the result in the Catalina source tree.
By the way, the Hydra Asset Manager has a loader that does something along the lines of what you want - i.e. you first load the loader (using another loader
I don't presently need such a general purpose loader. Instead, I have a separate target for each possible platform (to take into account the device and pin differences) and also a separate 'low level' loader - and there will be one of those for each possible combination of source (i.e. EEPROM, SD Card, Serial) and destination (i.e. HUB RAM or XMM RAM).
Using Catalina terminology, there are three main components required to get a program executing:
- The 'target' - this sets up all the device drivers and other plugins (e.g. real-time clock, floating point co-processor) that comprise the environment that the application code needs to execute.
- The 'loader' - this loads the application code into the correct place (or places) for execution - and then loads and starts the kernel.
- The 'program' or 'application code' - this is the compiled version of your C program.
So the type of loader I am talking about is probably a much lower level beast than the type of loader you are looking for.Typically, for LMM programs the target, loader and program are all compiled into one executable file. In practice, LMM programs don't need much a loader, since they are executed 'in place' in hub RAM - so the only job of the loader is to load and start the kernel.
But for EMM and XMM the target and loader are compiled together into one file (which is saved as a 32kb EERPROM image) which then sits around in the target directory until you have some application code that needs to use it - which is compiled into another file. This is why the EMM and XMM compile process appears to be 'opaque' - it isn't, but it may seem to be because it only compiles the C application code each time, whereas the LMM compile process compiles everything each time. If you want to see the rest of the EMM and XMM compile process, go to the target directory and enter 'build_targets' - but you don't usually need to do this unless you specifically want to change something in a target or in the Catalina_Common.spin file.
So ... getting back to the loader(s) ... at least in the Catalina meaning of the term ...
The EMM Loader is in the target directory. It is called Catalina_EMM_EEPROM_Loader.spin. As the name implies, it can only load from EEPROM, and it always loads into hub RAM. It always loads from address $8000 in the EEPROM.
The XMM Loader is also in the target directory. It is called Catalina_XMM_EEPROM_Loader.spin. Again, it can only load from EEPROM (and again, from address $8000) - but it loads into XMM RAM - and it currently only supports the Hydra Xtreme.
Hope this helps,
Ross.
EDIT: forgot to say - you should discard all the files from previous releases - e.g. the previous 'xmm_hires.spin' doesn't use the new 'Catalina_Common.spin' file.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 6/16/2009 2:08:47 AM GMT
Is the loader that you have really 32KB or is that just a 0 padded eeprom file?
Your intel-hex files contain many unnecessary 0 data lines ... how can they be removed?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
It sounds like you're using all the right parts. This could be a problem with my I2C implementation. There was no PASM driver for I2C when I started so I wrote my own - but of course it's only been tested on the Hydra. However, I think I saw somewhere that there is now a pure PASM I2C driver, so you could try that.
Yes, it's zero padded, and that 32k also includes all the drivers and plugins. The actual loader is pure PASM, so it is less than 2k.
Generate a binary ouptut instead of an eeprom - even if you subsequently generate intel-hex format, this causes the zero records to be left off the end. But there will still be some zero records in the middle - to eliminate those you would have to use the appropriate srecord options.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I will be writing minimal code to boot a binary from SD. I need to fit this "boot code" into a MC9S08 which will boot the RamBlade when no secondary prop terminal is available. I am hoping that I may be able to fit it into under 4KB.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Yes, I'm working on a loader that can load from a given file on SD.
Never enough time!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Ive finally managed to resolve an annoying problem with the Catalina code generator ... it is mentioned in the beta 4 release notes as follows:
Turns out to be a simple fix, but finding it has caused me to lose a lot of time on XMM support, so I don't plan to issue a new release just yet. However, if you want to recompile Catalina from source, the fix is a one line change to the function "clobber" (in source/lcc/src/catalina.md):
static void clobber(Node p) { assert(p); switch (p->op) { case CALL+F: spill(INTTMP | INTRET, IREG, p); spill(FLTTMP, FREG, p); break; case CALL+I: case CALL+P: case CALL+U: spill(INTTMP, IREG, p); spill(FLTTMP | FLTRET, FREG, p); break; case CALL+V: spill(INTTMP, IREG, p); // don't clobber our own target <=== THIS LINE CHANGED spill(FLTTMP | FLTRET, FREG, p); break; } }@Dale Stewart,
I promised (earlier in this thread) to report when my copy of the lcc book "A retargetable C compiler: Design and Implementation" arrived. Well it finally did - and while it did help me track down the abovementioned bug, I couldn't otherwise recommend it. It's almost unreadable. The big giveaway is on page 11 - despite the title, the authors acknowledge that there was no actual design phase for lcc. The book certainly shows evidence of this lack - it doesn't seem to follow any natural or logical order, or have any overall structure that I can discern. For example, by page 6 we're discussing abstract syntax notation trees, but basic language parsing is not covered in the main body of the book till page 100. Language declarations are not covered until page 250. The subject of the very first chapter (apart from the introduction) is ... wait for it ...memory allocation! The book is dated 1995, but it obviously has its roots deep in the 1970's when such things were "hot" research topics. While the content is undoubtedly still perfectly valid, starting the book this way just makes it seem very dated. And after starting out so badly, it fails to really improve much - it is very definitely a "bottom up" description of lcc. Perhaps the whole book is really intended to be read backwards.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
What, you mean this book is really about Forth?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have probably a little strange question: How many assmbler instructions of the propellers instruction set does your compiler use? Does it need all? Would it be possible to reduce the instruction set to use a processor with the most important 16 instructions of the propeller?
Thanks,
chris
In my opinion it is very bad idea.
For me it is same to buy " RoysRoys " and reconstruct is to " Fiat " for at I will have " Fiat "
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
First thing to do is to download Catalina and have a look in the lmm kernel module. All the instructions in there have to be working before any compiled C code will run.
Then perhaps Ross will tell you how many different PASM instructions can be generated by the compiler. Or again you can check the compilers code generator and count them yourself.
Anyway what you want seems unlikely to me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The code generator only currently generates about 30 different instructions - have a look in the file "source/lcc/src/catalina.md". But as heater says, the kernel will use a bunch more - have a look in the file "target/Catalina_LMM.spin"
However, I wouldn't guarantee that it will stay that way - I intend to go back and do more optimization over time, of both the Kernel and the Code Generator - so the instructions required may change.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Hey, you are one step ahead of Sapieha.
I was thinking of simply making statistics of the code. But I thought it's easier to ask the expert directly. I simply want to spare work by not have to implement all instructions.
Hi RossH,
Thank you for the answer. I will take a look at the *.md files.
chris
You said " I was thinking of simply making statistics of the code ".
That statisticas of code used by C and ASM on Intel's 8080-8085 CPU give os bad posiblites in Intel 8088-8086 code.
Them optimized out instructions from 8080 ASM set that have ben used not frequently.
And it result in optimising out all CALL on flags instructions !!
Regards
Christoffer
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Result, the 6809 ended up with no conditional CALLS as well !!
I always wondered if they just grabbed a load of listings and counted the occurrence of each instruction or if they actually ran the code to see what really got used most.
Makes one appreciate the Propeller way of handling conditional execution.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I must strongly encourage you to continue and expand your effort to emulation of all the instructions. After all there is only 64 opcodes, I'm busy working through 256+ for the 6809 emulator.
Be sure to take care of instruction timing and self-modifying code.
The result could be a nice fast Cog emulator that could be run on Windows or Linux or where ever and the Propeller community would love you forever.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thank you for that. I'm not sure yet, because for me it was only a try how difficult it would be to write an emulator.
With the structure of the existing code I have now it is easy to extend it. But it seems a lot of work ... Hmm, probably I will do it ...
> The result could be a nice fast Cog emulator that could be run on Windows or Linux or where ever and the Propeller community >would love you forever
Yes, you got the bigger goal. It would be very easy to transform the code to any platform ...
I was just having some questions about the different cogs. do i run _coginit(par, addr, cog) with par as the function name? and addr just as a random empty int?
No, the _coginit is a low level function to start a PASM program - it doesn't work like the SPIN function (which can start another SPIN function in a new cog).
Have a look at pages 284/285 of the Propeller manual (version 1.1) - the parameters to the coginit C function (i.e. par, addr, cogid) map to the destination register of the coginit assembly language instruction in a fairly straightforward manner, as follows:
par = bits 31:18 (i.e. the parameter to pass to the cog after startup)
addr = bits 4:17 (i.e. the long address of the code to load into the cog)
cogid = bits 3:0 new flag + cogid (i.e. the id of the cog to start, plus the new flag)
The C function does the shifting and combining required to put these parameters in the right places, but you must supply addr as a LONG address (dividing the actual address by 4). It points to 512 longs that represent the code. The par parameter can be any value (up to 14 bits) but is most often the address of a data block that contains configuration data for the cog - in which case it must also be divided by 4 (the reason I don't do the division by 4 automatically is that the par parameter may just be a value, not an address)
The fact that the cogid parameter also incorporates the new flag means a cogid of 8 will result in any free cog being used.
Here is a (non-working!) example of how I expected it would be used ...
#include <catalina_cog.h> #define COG 7 void main() { long code[noparse][[/noparse]512] = {0x12345678, 0x12345678, 0}; long data[noparse][[/noparse]32] = {1, 2, 3, 4}; int result; result = _coginit ((int)data>>2, (int)code>>2, COG); }However, while writing this post I just reviewed the code to check on the parameter mapping and noticed that the par parameter is not being passed correctly. I will issue a fix and generate a working example of how to use it later today.
Ross.
Edit: minor correction to code
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 6/27/2009 11:42:11 PM GMT
Post Edited (matb) : 6/28/2009 12:48:31 AM GMT
Yes, I agree my RTC implementation is pretty much a waste of a cog - I'll have a look at your code and see if I can find a way to use it instead.
I didn't worry too much about it because the Prop crystal is not really accurate enough to be an RTC anyway - my plugin is mainly intended as an example.
If you need accurate time, you would be better off adding an external RTC chip. There are several RTC chips with I2C interfaces that are very simple to integrate with - what I really should do for the next release of Catalina is include a general purpose I2C plugin that is accessible from C.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I've included a fixed 'coginit' function, and a demo program showing how to use it, in the file 'catalina_coginit_fix.zip' attached to the first post in this thread.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Infinity successfully compiled beta 3 under OSX using gcc. I incorporated a couple of minor changes into the beta 4 makefiles as a result of his experience, so I believe it should now compile "out of the box" - but I don't have a Mac so I can't guarantee this.
You will also need to install mono in order to run homespun (same as for Linux).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
So do i see it right that i need to convert the code to hex first before it can be run on a new cog?
and is data going to be globally accessible for other cogs to communicate with one another?
I am not a fan of editing Catalina_Common.spin for different boards to define the pinouts. I figure a #define in any spin plug-ins would be really useful mechanism that would solve it.
An alternative would be to pick up Catalina_Common.spin (or similar) in a local directory, instead of from the common library directory, using a include path type mechanism. I quickly tried that, but I suspect the -T Catalina argument does not support it.
The spin mechanism of 'importing' constants is pretty frustrating. One of the reasons for me to try C instead.
m@
I'm thinking of implementing an 'asm' function, but it's not part of the ANSI standard. So yes, you have to currently specify PASM instructions in hex. The easiest way at the moment to get the required hex is to use Homespun to compile the PASM, and use the Homespun -d option to produce a list file - then cut and paste the bytes from that file. Be careful about byte ordering - homespun prints each long as 4 bytes, so it may be easier to represent the data in Catalina as an array of bytes - or if you want to represent it as longs you need to reverse the order of the bytes in each long.
But there is another, even easier way - each target has a file called something like 'catalina_target.s' where you can simply insert PASM instructions or data. For example, the default target has one called ' catalina_default.s' - add your PASM program to this, making sure your main symbol is prefixed by "C_" and is all lower case and has no other underscores - e.g. "C_mycode". Then you can refer in your C program to the symbol as simply "mycode". The binder will initially complain that this symbol is undefined, so you need to use the '-f' option to the binder (or the '-Wl-f' option to lcc) to force the binder to continue even if it has undefined symbols (it finds it later in the binding process).
Making data globally accessible between cogs is up to you - if all your coginit functions use a common data pointer (i.e. one declared as a static in C), then yes - all cogs will see the same data. I use this trick a lot - ff you also need to pass individual data to each cog as well as shared data, then have each cog retrieve its own id and use this as an index into an array of cog-specific data.
@matb,
I don't think homespun accepts #defines on the command line. But using the -T switch to the binder (or -Wl-T to lcc) to specify an alternate target directory works for me.
For example, I'm currently working on a set of targets for the Hybrid. So I created a copy of the target directory, called it 'hybrid', and I now compile for the Hybrid by saying something like:
Of course it's easier if you use a batch file or a makefile. Note the need for using the short version for all path and file names.
Ross.
Edit: PASM for the default target should be included in the file called "catalina_default.s", not "lmm_default.s"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 6/28/2009 6:37:27 AM GMT