ICC C Compiler NC version wilol no longer have 16K limit
ImageCraft
Posts: 348
We are working on the final touches for the next release. Among other things, it will eliminate the 16K limit in the NC (non commercial use) version. Current owners will of course be able to take advantage of it by upgrading to the latest.
// richard
// richard
Comments
Ron
Roy
p.s. I hope you haven't changed the kernel too much, so that I can fit my changes in for the debugger I'm working on. [noparse]:)[/noparse]
In fact, if the debugger needs *less space* than we reserve space for, may be we can reclaim some
It dujmps the registers (R0-15, USER0-5, PC, CRSP, HRSP, and the flags) plus the stack to hub memory nd then spins waiting to be told to continue, so it's not too much.
I also added a bit of code to the finit function to clear the registers and stack so that debugging can start from a known state, but that only needs to be around at startup.
???? Any hints as to what this will allow you to do?
Minix here we come!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
now this is getting interesting.
I design and make specialist products for the entertainment industry. Up until now I've been using multiple 8-bit (AVR) MPUs, sometimes with 3 or 4 per PCB. If I want a UART I don't buy one; I turn an MPU into one. I've been attracted to the Propeller for 2 main reasons...
1) Having 8 MPUs in one package and...
2) The video capability.
However, what's been holding me back from putting into into my next unit is...
1) Having to learn yet another language/instruction set in the form of spin and pasm as I already use ICCAVR
2) The lack of RAM, I don't need huge amounts but often need a few 8k byte buffers
In an ideal propeller powered world I'd be able to program in 'C', not have to worry about code space too much (again, I don't need huge amounts, on an AVR it's often no more than 32k bytes across multiple chips), have easy access to 16-24k of data RAM and easily run IO objects on other COGs which get their data from the HUB.
Is your external memory version going to pull data in via SPI completely on the fly or is there some buffering going to go on? How much HUB will this scheme free up for data? Will you be able to store binaries for other COGs in the external memory and load them up as needed? Sorry, so many questions.
Prop is so different, I doubt you could do much at all without a reasonable knowledge of Spin and a little PASM.
That is not to take anything away from the Imagecraft product. There are very few drivers available and you·might find it very
difficult to implement them without some knowledge of Spin and the way it manages Cogs.
Ron
Post Edited (Ron Sutcliffe) : 9/17/2008 9:32:34 AM GMT
Remember this is in the prototype stage, but according to Jazzed and others, it *should be* possible to pull data off external flash almost as fast as the Hub RAM. Software wise, we would need to change the LMM instruction fetch loop to fetch from the external memory.
The compiler does not need to change for this as this is just changing the kernel routine. In fact, if we leave literals and constant items etc. to stay in Hub RAM, then there should not be any changes to the compiler at all. This means that a pre-built .o or .a library file can be used in any project regardless whether Hub RAM or external memory is used in the final output. The linker will need a new option for it to build external memory program, mostly meaning that it needs to generate two output files: a .binary that holds the kernel and the literals, constants for the Propeller memory, and a .hex/.bin file for the external memory that holds the actual program.
A further refinement would be to put the literals and constants in the external memory as well leaving almost all Hub RAM to data. This would involve very minor compiler change but the stumbling block is that we are having trouble fitting the "fetch literal in ext memory" instruction into the kernel code. So I will probably wait until the dust settles a bit regarding debugging support to see if we can reclaim some reserved space there to decide whether to support this refinement or not.
As for invoking other Cogs, we *should be* able to invoke LMM C functions in other Cogs without any changes as we are just launching LMM C kernel in the other Cog. For PASM-style native code, if we bind them to the Hub RAM image (e.g. along with the kernel and the literals), then nothing also needs to change and you can just do a cognew_native on them as you currently would.
At least that's the theory. Note that in another thread, Roy and Jazzed request that we to allow pre-built .binary fragment (typically a native driver code) to be used. I don't see why we cannot support that in theory. So there will be 3 ways to write driver code: the current two of a) write it as a .s asm file, b) convert it has a C array, and (new) c) include a .binary file in the project.
So yes, Minix is decidedly possible!
// richard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again
BTW: I type as I'm thinking, so please don't take any offence at my writing style
I, and it's obvious that many others are pleased that you have decided to remove the 16k limit·on your Non commercial version. This really has got to be a good move
I·have raised this before albiet indirectly,·but I wonder if you would consider·upgrading the Terminal feature to·send keyboard escape· sequences etc. This would greatly·assist·when using the terminal·to debug code. Having to switch between Hyperterm,·Realterm etc is a pain, especially when your own IDE·provides almost everthing else. (no debug, but·users already know that, and it is well documented)·
Ron
Will it be possible to hack around with the kernel to read from those RAMS ?
If so, that would spur me into action to build this thing as it would then have other interesting uses.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://forums.parallax.com/showthread.php?p=650217
meow, i have my own topic now? (sorta)
Some keys such as the Arrow keys, UP, Down , LEFT and RIGHT generate a string of· three and sometimes four bytes.· The Esc SEQ for arrows starts· with 0x1b, 0x5b followed by the key code 0x31 or 0x32 or 0x33 or 0x34 depending up the arrow key pressed.·
If I recall the ICC terminal issues only 0x1b for these keys. Hence they cannot be decoded on the receive side. Windows(dare I say) on the recieve side takes the last byte in the Esc Seq and adds 0x80 so we end up with· 0xc1, 0xc2, 0xc4, 0xc4 which the Windows Display Driver interprets as an arrow func.·
All I would like to see is that the ICC terminal issues these byte sequences so that all the keys on the keyboard can be used.· I would not want to see
the ICC terminal window issues a single bytecode 0xc? as used by the windows display (I think PC_Keyboard uses such a system). Far better that the keyboard sequence be trapped and handled on the recieve side by the user program.·
Ron
The IBM PC Scan Codes comes to mind, don't·care what scan code standard is used, but it would be great if it could be implelemented.
···
Post Edited (Ron Sutcliffe) : 9/19/2008 9:34:49 AM GMT
It should be possible - Richard would have to confirm what access there is to the Kernel for the non-commercial version.
Although you have the RAM ( so it's effectively free of cost ) it might be better to see what ImageCraft chooses and adopt the same - or even buy their hardware. You'll get the same end result, have more I/O free for use, and, best of all, others will be able to benefit from the work you do with CP/M - you won't be the only person in the world with that particular hardware configuration !
I think this extended memory mode ( shall we call it "XMM" ? ) is a brilliant idea, both for ICC and other uses. Whatever ImageCraft settle upon I think will become the de-facto reference design for the future.
I'm sure if ImageCraft specify something it would become a standard of sorts but others will always want to experiment with different/newer RAMS or other devices. What if I want ROM based code for example ?
Yes, my RAMs are free, except for the investment in time to wire them up or make a PCB and as you say no one else will have it which is what has really stopped me so far. So an ImageCraft "XMM" specification would be great.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
re: double precision
First we have to support single precision!