Another of the big features was this great forum. Unfortunately, for whatever reason, this is no longer really true anymore. Many of the regulars have left. I have no idea where they went, otherwise I might join them
I wonder about them, too. I suppose the ongoing development got frustrating and wasn't so interesting, after a while. I, too, wonder what they are doing and if a real Prop2 would bring them back.
I'm glad you guys are still around, though!
Your new forum software is not as nice to use as the old VBB, sad as it is to say. The layout and format is just funky. Also, with development taking so long (yeah, it was really 4 years ago I wrote that SHA256 stuff) life has pointed in other directions. For me at least, I've got a million ideas, but realistically 1 day a week to focus on so many projects. I've got an interesting project that's been sitting on the back burner for a month because of other, more pressing, matters.
Another of the big features was this great forum. Unfortunately, for whatever reason, this is no longer really true anymore. Many of the regulars have left. I have no idea where they went, otherwise I might join them
I wonder about them, too. I suppose the ongoing development got frustrating and wasn't so interesting, after a while. I, too, wonder what they are doing and if a real Prop2 would bring them back.
I'm glad you guys are still around, though!
Your new forum software is not as nice to use as the old VBB, sad as it is to say. The layout and format is just funky. Also, with development taking so long (yeah, it was really 4 years ago I wrote that SHA256 stuff) life has pointed in other directions. For me at least, I've got a million ideas, but realistically 1 day a week to focus on so many projects. I've got an interesting project that's been sitting on the back burner for a month because of other, more pressing, matters.
The problem with the prior setup was that it was slowly becoming buggy because of operating system changes and the software was not being maintained by its developers. Now we have Hello Kitty.
I'm not probing for any redesign effort. I think P2 is good the way it is.
Phew !
I just feel like I've been in a coma for the last ten years, maybe drifting and unaware of what else has been going on.
Perhaps you should not worry about that so much. With the rate things change now a days if you take a catnap you wake up to an unrecognizable world.
Still there is nothing like a Propeller out there.
The trick now is in ensuring it's dead easy to use. I don't think Spin is the answer there, far too non-standard.
I have fantastical dreams about being able to program a P2 in Javascript. That would attract a lot of people now a days. That's not much use for fast-real time work so in my fantasy there would be a dead easy way to include C/C++ code into the same project for execution on other COGs. Even assembler.
Basically JS would replace the role of Spin, and a lot of what we have to do in PASM in a Propeller project can be replaced with natively compiled C/C++.
A tiny opensource JS engine by Samsung for very small systems. <64 KB RAM and <200 KB ROM.
Seems to be quite new. I was just trying to find a small JS engine that I spotted some months ago. Could not remember what it was called. Anyway Google found me jerryscript.
Seems my fantasy is coming to reality. I'm not the only crazy person who wants JS on micro-controllers. Samsung is crazy too! This makes it incredibly easy to have a nice easy JS language for new comers and all those web monkeys that want to mess with controllers. And do hard real-time stuff drivers an such in C/C++/PASM.
A tiny opensource JS engine by Samsung for very small systems. <64 KB RAM and <200 KB ROM.
Seems to be quite new. I was just trying to find a small JS engine that I spotted some months ago. Could not remember what it was called. Anyway Google found me jerryscript.
Seems my fantasy is coming to reality. I'm not the only crazy person who wants JS on micro-controllers. Samsung is crazy too! This makes it incredibly easy to have a nice easy JS language for new comers and all those web monkeys that want to mess with controllers. And do hard real-time stuff drivers an such in C/C++/PASM.
What is this JS engine written in? Is it some kind of interpreter? How do you get JS source code to run in it?
I looked at some Java Script code and it seems very readable. Looks like Verilog to me now.
Ha, I just downloaded, compiled and ran Jerryscript here. It's all written in plain C. Worked out of the box. Magic.
Basically you get your Javascript source code into a string in C. By whatever means. Then you use the Jerryscript library to interpret/run that string. Like so:
All that needs is a simple command line input to the Prop and people can just type in JS and run it!
Not only that they could spin up Javascript on more than one COG at a time, how cool would that be?
Of course there is a ton of other functions in the Jerryscript library to initialize a JS work space, interact between JS and C, etc etc. I have to look into it.
There is also the V7 Javascript engine. Also very small and works in much the same way. I think V7 is the engine I was looking for earlier today.
Time to try and get this running on my Gadget Ganster Prop board with the huge external memory. See you later....
Ha, I just downloaded, compiled and ran Jerryscript here. It's all written in plain C. Worked out of the box. Magic.
Basically you get your Javascript source code into a string in C. By whatever means. Then you use the Jerryscript library to interpret/run that string. Like so:
All that needs is a simple command line input to the Prop and people can just type in JS and run it!
Not only that they could spin up Javascript on more than one COG at a time, how cool would that be?
Of course there is a ton of other functions in the Jerryscript library to initialize a JS work space, interact between JS and C, etc etc. I have to look into it.
There is also the V7 Javascript engine. Also very small and works in much the same way. I think V7 is the engine I was looking for earlier today.
Time to try and get this running on my Gadget Ganster Prop board with the huge external memory. See you later....
Do we need 64-bit floats to do this well? Are we never going to be able to go back to 1980?
Do we need 64-bit floats to do this well? Are we never going to be able to go back to 1980?
The Memory needed seems to be some portions of MBytes, so no, we are not getting back to 1980....
64 Float is the default type, and there is some bit-ops that expect 32b numbers, so 32b Float is not really a fall-back.
"For JerryScript, we also support a build option 'compact profile' which results much smaller footprint with limited features of ECMA-262 standard. It can run on only 8KB start up RAM with less than 100KB of flash memory. In conclusion, such an approach depends on what we should support or what we shouldn't."
Jan 31: "For example, the JerryScript team has just finished the development of Compact Byte Code, which is a variable length byte code with lightweight data compression called opcode morphing. It combines high performance (15% faster) with small byte-code size (around 50% saving). We are very proud of this achievement and I think it is worth to publish a paper about our findings."
Tho their own plots do not quite reach that 15% / 50% claim.... CBC has improved things.
Not quite sounding like multiple one-per-COG use, but possibly a good chunk of P2 could support this in ONE COG ?
Ha, I just downloaded, compiled and ran Jerryscript here. It's all written in plain C. Worked out of the box. Magic.
If you like Interpreted Languages, I also found this, http://www.xpl0.org/
which has the bonus of a Compiler too.. :
XPL0 Programming Language 16-Bit Versions
Less cryptic than C
Less restrictive than Pascal
More powerful than BASIC
Three compilers:
* Interpreted
* Native
* Optimizing
Cross-reference utility
If these things would allow the Prop2 to run earlier than a custom tool effort would provide, there's value in that; especially if these languages are known by lots of people.
Their devices which have been in production for three or four years will compete directly with the P2. Interestingly, I don't think I've ever seen them mentioned by Chip! Perhaps he is worried about them.
Do we need 64-bit floats to do this well? Are we never going to be able to go back to 1980?
All numbers in JS are 64 bit floats. We have just learned here that the little embedded JS engines do everything in integer arithmetic even when their target has floating point support, if it's only 32 bit floats.
As jmg says, we can't really use 32 bit float because it really buggers up many things in the language. For example programs can expect to rely on exact integer results, say when counting time, up to the 53 bits that is the mantissa of a 64 bit float representation.
Are we never going to be able to go back to 1980?
Hey, I never left 1980
@jmg
The Memory needed seems to be some portions of MBytes, ... Not quite sounding like multiple one-per-COG use, but possibly a good chunk of P2 could support this in ONE COG ?
The Jerryscript interpreter is 250KB on my Linux machine here. OK, that's half the P2 RAM gone in interpreter code.
BUT, perhaps that code can be run by many COGs simultaneously. They each get their own work space.
XPL0 is interesting. A historical artefact from 1976. I'm thinking we need something more main stream and standard though, not YAFL
Their devices which have been in production for three or four years will compete directly with the P2. Interestingly, I don't think I've ever seen them mentioned by Chip! Perhaps he is worried about them.
I might, but there are too many other things I need to worry about. Competition for worry is keen.
Hmm...pretty good. Might have to look into that more. Looks like it's 256K per core though.
I wish they would stop calling hardware time sliced threads "cores". What they actually have is 8 threads per core and one, two, four cores.
I wish Parallax would stop calling their cores "COGs". :-)
Maybe we should just accept this unfortunate naming and take a look at what the XMOS chips really offer like we wish potential Parallax customers would with the Propeller. I'm not saying XMOS chips are better or worse but condemning them because of bad naming choices seems kind of silly.
Yes I did. I a logical kind of way. It was during the old P2 time sliced treading discussions I think.
But it's not the reality in silicon. It's also not the reality in operation the way XMOS has done it. Run 1 to 4 threads and they all achieve the peek MIPs but run 5 to 8 threads and things start to slow down. Their threads can "modulate" each others timing as things get started and stopped.
It's deceptive marketing.
At least they do label their threads as "logical cores" in the architecture diagrams.
At least the operation can be simulated accurately, and the performance predicted, with the software tools provided. Moreover, assembler isn't required for deterministic operation, as is the case for the P1 and P2. I think that is a big selling point. I don't think that Parallax makes that clear in their marketing.
Basically JS would replace the role of Spin, and a lot of what we have to do in PASM in a Propeller project can be replaced with natively compiled C/C++.
I won't comment on Spin, but PASM is an absolute key feature. C is fast and can be compact and I am more than comfy with it but just doesn't deliver that instruction counting precision that is bred and butter on the Prop.
PS: I like instruction counting as a valid crafting tool.
Wow, that little board has a lot packed into it. Ethernet, WIFI, USB, GPIO including analog.
Interesting board, for sure! But more germane to the marketing of P2 is the fact that the Tessel 2 has modules. That is definitely a trend that has come along in recent years. The obvious forerunner to this are the Arduino shields. But it seems that every major dev product out there has started doing their own variation. You don't just get a demo board with a new processor design; you get a dev board with a myriad of pluggable modules. At first, the processor choice is somewhat immaterial, except possibly in it's capacity to make something easier to accomplish than competing processors would. The big thing is: grab a dev board, connect some useful modules, program something interesting in a familiar language, and go! From there, whether a user delves into the particulars of the processor depends largely on what they intend to do with their creation. Commercial-minded users (and hardcore hobbyists) are likely to to convert that into a single-board design, and will therefore want to get "closer to the metal".
And here is where the P2 can really shine. Its I/O flexibility allows users to trivially connect modules in ways that just cannot be done on any other (similar) platform. Module Mastery! (tm it quickly, @KenGracey!) That is the hook that will put P2s in front of users. From there, the users will naturally want to learn more about the underlying architecture, which will lead to raw P2 sales.
Basically JS would replace the role of Spin, and a lot of what we have to do in PASM in a Propeller project can be replaced with natively compiled C/C++.
I won't comment on Spin, but PASM is an absolute key feature. C is fast and can be compact and I am more than comfy with it but just doesn't deliver that instruction counting precision that is bred and butter on the Prop.
PS: I like instruction counting as a valid crafting tool.
[Sigh....] And PropBASIC still is ignored. CREATED FOR the Prop, dead easy to use, PASM performance.
@Heater - I know that you follow the RISC V development. Any comment on lowRISC's Minion cores versus COGs? It seems like this is still in development?
Their devices which have been in production for three or four years will compete directly with the P2. Interestingly, I don't think I've ever seen them mentioned by Chip! Perhaps he is worried about them.
It seems that you are constantly shilling for XMOS on this forum. Please stop.
While LowRISC's minion cores are mostly speculation, TI has PRU's for it's ARM SOC's that do the same thing. Freescale has a similar architecture on it's higher end automotive offerings based on eTPU.
Now neither is like the Prop, where you have a bunch of generic cpu's but rather several high speed dedicated RISC engines with their own memory sub-systems that take care of all I/O while the main CPU does what it's good at.
Comments
Your new forum software is not as nice to use as the old VBB, sad as it is to say. The layout and format is just funky. Also, with development taking so long (yeah, it was really 4 years ago I wrote that SHA256 stuff) life has pointed in other directions. For me at least, I've got a million ideas, but realistically 1 day a week to focus on so many projects. I've got an interesting project that's been sitting on the back burner for a month because of other, more pressing, matters.
The problem with the prior setup was that it was slowly becoming buggy because of operating system changes and the software was not being maintained by its developers. Now we have Hello Kitty.
Still there is nothing like a Propeller out there.
The trick now is in ensuring it's dead easy to use. I don't think Spin is the answer there, far too non-standard.
I have fantastical dreams about being able to program a P2 in Javascript. That would attract a lot of people now a days. That's not much use for fast-real time work so in my fantasy there would be a dead easy way to include C/C++ code into the same project for execution on other COGs. Even assembler.
Basically JS would replace the role of Spin, and a lot of what we have to do in PASM in a Propeller project can be replaced with natively compiled C/C++.
A tiny opensource JS engine by Samsung for very small systems. <64 KB RAM and <200 KB ROM.
Seems to be quite new. I was just trying to find a small JS engine that I spotted some months ago. Could not remember what it was called. Anyway Google found me jerryscript.
Seems my fantasy is coming to reality. I'm not the only crazy person who wants JS on micro-controllers. Samsung is crazy too! This makes it incredibly easy to have a nice easy JS language for new comers and all those web monkeys that want to mess with controllers. And do hard real-time stuff drivers an such in C/C++/PASM.
Edit: This is serious. There is even a jerryscript workshop next week at Samsung's R&D Institute in England. https://github.com/Samsung/jerryscript/wiki/JerryScriptWorkshopApril2016
What is this JS engine written in? Is it some kind of interpreter? How do you get JS source code to run in it?
I looked at some Java Script code and it seems very readable. Looks like Verilog to me now.
Who is near there ?
The secondary link http://www.jerryscript.net seems to be down ?
The targets list seems to be
esp8266
FRDM-K64F board.
stm32f4
and talk about MIPS and RaspPi...
What is P2 performance like on 64b Real ?
I see some benchmarks here :
http://samsung.github.io/jerryscript/benchmark/benchmark.html
One example shows memory pushing to 600k, but does no split Code:Data
Basically you get your Javascript source code into a string in C. By whatever means. Then you use the Jerryscript library to interpret/run that string. Like so:
#include <string.h> #include "jerry.h" int main (int argc, char * argv[]) { char script [] = "print ('Hello, World!');"; jerry_completion_code_t code = jerry_run_simple (script, strlen (script), JERRY_FLAG_EMPTY); }How easy could it be?All that needs is a simple command line input to the Prop and people can just type in JS and run it!
Not only that they could spin up Javascript on more than one COG at a time, how cool would that be?
Of course there is a ton of other functions in the Jerryscript library to initialize a JS work space, interact between JS and C, etc etc. I have to look into it.
There is also the V7 Javascript engine. Also very small and works in much the same way. I think V7 is the engine I was looking for earlier today.
Time to try and get this running on my Gadget Ganster Prop board with the huge external memory. See you later....
setInterval (function () { // Do something here... }, 100);Which runs the "function" every 100ms.I'd love to see something like:
setCog (function (in, out) { while (1) { x = in(); out(x * 2) } }, 7);Which runs the function on a separate COG and provides some input and output mechanism to hook it up to the parent JS:Do we need 64-bit floats to do this well? Are we never going to be able to go back to 1980?
64 Float is the default type, and there is some bit-ops that expect 32b numbers, so 32b Float is not really a fall-back.
I also find these comments : here https://github.com/Samsung/jerryscript/issues/768
"For JerryScript, we also support a build option 'compact profile' which results much smaller footprint with limited features of ECMA-262 standard. It can run on only 8KB start up RAM with less than 100KB of flash memory. In conclusion, such an approach depends on what we should support or what we shouldn't."
Jan 31: "For example, the JerryScript team has just finished the development of Compact Byte Code, which is a variable length byte code with lightweight data compression called opcode morphing. It combines high performance (15% faster) with small byte-code size (around 50% saving). We are very proud of this achievement and I think it is worth to publish a paper about our findings."
Tho their own plots do not quite reach that 15% / 50% claim.... CBC has improved things.
Not quite sounding like multiple one-per-COG use, but possibly a good chunk of P2 could support this in ONE COG ?
If you like Interpreted Languages, I also found this, http://www.xpl0.org/
which has the bonus of a Compiler too.. :
XPL0 Programming Language 16-Bit Versions
Less cryptic than C
Less restrictive than Pascal
More powerful than BASIC
Three compilers:
* Interpreted
* Native
* Optimizing
Cross-reference utility
If these things would allow the Prop2 to run earlier than a custom tool effort would provide, there's value in that; especially if these languages are known by lots of people.
http://www.xmos.com/
Their devices which have been in production for three or four years will compete directly with the P2. Interestingly, I don't think I've ever seen them mentioned by Chip! Perhaps he is worried about them.
As jmg says, we can't really use 32 bit float because it really buggers up many things in the language. For example programs can expect to rely on exact integer results, say when counting time, up to the 53 bits that is the mantissa of a 64 bit float representation. Hey, I never left 1980
@jmg The Jerryscript interpreter is 250KB on my Linux machine here. OK, that's half the P2 RAM gone in interpreter code.
BUT, perhaps that code can be run by many COGs simultaneously. They each get their own work space.
XPL0 is interesting. A historical artefact from 1976. I'm thinking we need something more main stream and standard though, not YAFL
I might, but there are too many other things I need to worry about. Competition for worry is keen.
Their I/O is not very flexible though.
So any of their devices have 512K RAM! Last I checked it was 64K per core share among 8 threads. Many device only have 1 core.
That bloody Eclipse IDE you have to use puts me off.
http://www.xmos.com/products/silicon/xcore-200/xl-series
I wish they would stop calling hardware time sliced threads "cores". What they actually have is 8 threads per core and one, two, four cores.
They call them 'logical cores' in the data sheet.
I think you pointed out a long time ago that the XMOS 'cores' are equivalent to Prop cores.
Maybe we should just accept this unfortunate naming and take a look at what the XMOS chips really offer like we wish potential Parallax customers would with the Propeller. I'm not saying XMOS chips are better or worse but condemning them because of bad naming choices seems kind of silly.
But it's not the reality in silicon. It's also not the reality in operation the way XMOS has done it. Run 1 to 4 threads and they all achieve the peek MIPs but run 5 to 8 threads and things start to slow down. Their threads can "modulate" each others timing as things get started and stopped.
It's deceptive marketing.
At least they do label their threads as "logical cores" in the architecture diagrams.
I won't comment on Spin, but PASM is an absolute key feature. C is fast and can be compact and I am more than comfy with it but just doesn't deliver that instruction counting precision that is bred and butter on the Prop.
PS: I like instruction counting as a valid crafting tool.
Interesting board, for sure! But more germane to the marketing of P2 is the fact that the Tessel 2 has modules. That is definitely a trend that has come along in recent years. The obvious forerunner to this are the Arduino shields. But it seems that every major dev product out there has started doing their own variation. You don't just get a demo board with a new processor design; you get a dev board with a myriad of pluggable modules. At first, the processor choice is somewhat immaterial, except possibly in it's capacity to make something easier to accomplish than competing processors would. The big thing is: grab a dev board, connect some useful modules, program something interesting in a familiar language, and go! From there, whether a user delves into the particulars of the processor depends largely on what they intend to do with their creation. Commercial-minded users (and hardcore hobbyists) are likely to to convert that into a single-board design, and will therefore want to get "closer to the metal".
And here is where the P2 can really shine. Its I/O flexibility allows users to trivially connect modules in ways that just cannot be done on any other (similar) platform. Module Mastery! (tm it quickly, @KenGracey!) That is the hook that will put P2s in front of users. From there, the users will naturally want to learn more about the underlying architecture, which will lead to raw P2 sales.
[Sigh....] And PropBASIC still is ignored. CREATED FOR the Prop, dead easy to use, PASM performance.
It seems that you are constantly shilling for XMOS on this forum. Please stop.
Now neither is like the Prop, where you have a bunch of generic cpu's but rather several high speed dedicated RISC engines with their own memory sub-systems that take care of all I/O while the main CPU does what it's good at.