I meant a version of JavaScript that had 48 bit floats (32 bit mantissa, 15 bit exponent, 1 bit sign) or something similar; a format that is not necessarily IEEE compliant but would be more efficiently implemented in software. Or even a format has the same structure as a 64 bit IEEE double but with only 32 significant bits, the remaining 20 or so always being 0. The performance of such a format could be quite a bit better than standard IEEE format.
The use of a format like this would only be for performance reasons. PropGCC already supports 64 bit IEEE doubles, but they're not particularly fast.
I meant a version of JavaScript that had 48 bit floats (32 bit mantissa, 15 bit exponent, 1 bit sign) or something similar; a format that is not necessarily IEEE compliant but would be more efficiently implemented in software. Or even a format has the same structure as a 64 bit IEEE double but with only 32 significant bits, the remaining 20 or so always being 0. The performance of such a format could be quite a bit better than standard IEEE format.
The use of a format like this would only be for performance reasons. PropGCC already supports 64 bit IEEE doubles, but they're not particularly fast.
Sounds worth exploring.
I guess a benefit of a 64b IEEE subset is things like printf could be used (ie C code could access variables created using the optimized Float )
Sigh, are we going to go through the sausage making circle again? ...One month people are arguing "Ship It!", the next it 'Oh Shiny!"...
No. No need to be grouchy. My wanting JS on the P2, or anyone else wanting any other language does not call for a new round of sausages. Unless it's a really minor tweak perhaps.
My 64 bit Propeller statement was only an aside.
I'm with you. I want a P2 ASAP.
Was only a little grouchy, just surprised to check back in and find a full blown discussion starting that seemed to be another potential delay. I thought we were all wrapping up with USB/SmartPins done, and boot sequence the last mile...
... I thought we were all wrapping up with USB/SmartPins done, and boot sequence the last mile...
Nearly....
I think USB test coverage is still not complete, and all smart pin modes are not test-covered either ?
Boot is looking close, and some P2 software is even coming along...
Ha, ha, an oft' quoted jape with a lot of truth behind it. In this case though, no. If you want Javascript there is only one standard, ECMA-262.
@Eric,
Your suggestions make a lot of sense. Particularly "...same structure as a 64 bit IEEE double but with only 32 significant bits"
I'm not really into the idea as potentially it's a lot of work to make it work. Creating a whole new float format and perhaps tweaking any JS engine to use odd sized numbers. And at the end of the day would it be significantly faster in an overall program?
The solution is just software routines to compute double-precision floats, isn't it?
Indeed.
I think the focus of the conversation has blurred a bit. I believe Heater was asking whether we could take advantage of the CORDIC engine to get somewhat-faster-than-typical software support for 64-bit floats. People instead focused on the fact that he said "JavaScript". But I think the question has merit independently of programming language. 32-bit and 64-bit floats are common occurrences in software, so efficiently supporting them is a worthwhile endeavor.
For instance, at one point, I vaguely recall that you could have up to two (or was it three?) operations from the same cog semi-concurrently working through the CORDIC engine. Can we take advantage of that feature to partition the floating-point math in such a way that multiple parts of the same floating point operation can be worked on "at the same time"? And would this be any faster than the traditional software approaches that already exist?
Surely if the P2 is to ever gain any sort of commercial acceptance...
Acceptance by whom, and for what? There are a hundred billion microcontrollers in this world that don't implement 64-bit floating point operations in hardware.
Surely if the P2 is to ever gain any sort of commercial acceptance...
Acceptance by whom, and for what? There are a hundred billion microcontrollers in this world that don't implement 64-bit floating point operations in hardware.
He was speaking toward the use of standard floating point formats, not whether the propeller should have a FPU.
Yes, I was fishing for a way to use CORDIC to help with software that implements 64 bit floats. Turns out this is not viable. So that's it.
Why not? You could use the CORDIC to help with a 64x64 multiply by having it do three of the 32x32 multiplies at once, and while you're waiting to queue each operation and to receive each result, you could do the other 32x32 multiply by using the 16x16 MUL instruction four times. This would probably be faster than the non-CORDIC alternative of just using MUL 16 times.
I have no idea "Why not". Clearly I'm not up to speed on what can be done with the CORDIC engine. Especially in parallel.
Now, I'm not about to start trying to create a IEEE 754 compliant floating point library, using CORDIC or not.
So, if anything happens with JS at all it will depend on a C++ compiler with 64 bit float support. GCC and others can provide that in software using integer ops, ADD, SHIFT, etc. Or presumably making use of a normal MUL instruction if there is one.
The solution is just software routines to compute double-precision floats, isn't it?
Yes, that is one approach. Some are ok with the low speed that will result - I'm guessing it will be faster than Basic Stamp, and some do still buy that.
Given the bottle neck here, this probably needs at least one COG dedicated as a JS-FPU.
First is the loathing of anything Javascript by many. That's OK. It's normal language war stuff.
I'll make a belated clarification since this is in reference to my adverse statements, I'd like to make clear my "loathing" is specifically of client side scripting in web browsers. It matters not of which language may be performing this function. Tack in a different scripting language to the browser and I'll loath it just the same. So, it's not the language per-se I dislike but just the environment it was born of. Javascript will be loathed as long as it is used in web browsers.
I think we can all agree with you the heinous state of the web. That is web browsers. What with all the links to advertising, code being pulled in from all kind of places we did not order, pop-ups, auto playing videos, tracking this, spying on that. Security is a mess. From a developer perspective the entire browser platform is hideous, with it's babel of synataxes: HTML, CSS, JS, SVG etc, all mixed up.
But I don't think it's the fault of Javascript as such. Although for sure it can help people with all those hideous practices.
Tracking, spying, browser (hence user) profiling, animations, and so on can all be done without Javascript. Ever hear of "web bugs"? https://en.wikipedia.org/wiki/Web_beacon
Certainly all those sites that depend on ad revenue have an easy time. All they have to do is put some links into the pages they serve. The advertisers do the rest via the JS pulled from those links. BUT if we all stopped using JS tomorrow they would find a way around it. All they have to do is get the sites to run software on their servers that injects the advertising/tracking material into the HTML they are serving. Facebook is already working on this because of the popularity of adblock.
Also remember that back in the day it was Java that was supposed to do all of this in the browser. At least that was the Sun Netscape deal. So you should find Java pretty loathsome to.
Then there was MS with it's "Active" whatever system. That makes Visual Basic loathsome. Not to mention all the other languages that "Active" whatever could be used with.
Then there is Google with it's Native Client idea. With that C/C++ and whatever can be compiled can be used in the browser. That would make all those languages loathsome.
Basically you are blaming the son (JS) for the sins of the father (the browser platform).
It's the browser that makes all this mess possible. For example: When I go to a web site that I trust a bit, say forums.parallax.com, how come my browser ends up talking to http://www.gravatar.com/avatar.php? and fetching script from "https://connect.facebook.net/en_US/all.js#xfbml=1" whom I don't trust at all, especially the latter. How come my browser allows that? How come there is no way I can disallow it?
Meanwhile, JS is a language like any other. JS in the browser allows us to do many wonderful things that cannot be done without. JS stand alone is a great programming language for systems, hardware and software, large and small.
.... JS stand alone is a great programming language for systems, hardware and software, large and small.
Yay Javascript
Hehe, maybe if you redefine 'small' sufficiently, that can be true.
In the Microcontroller / embedded space, small starts at 1~2k, and even though that is moving up*, it is not moving up quickly enough yet, for inefficient languages.
* I can now get, for sub 30c, an 8 bit MCU with 16k of Flash.
That is enough to manage 32b Float / 32b int, in mature, efficient Compilers like C, Pascal, Modula-2 or Basic.
Five years ago, smallest MCUs pretty much had to be coded only in Assembler.
Now, 16k for sub 30c is a new 2016 point, so who knows what the 'small' will be in 5 years...
I started out in the era when great big DIP packages held 8 bit micro-processors. To which you had to add RAM and ROM, and all kind of support chips, timer, UART, PIO, interrupt controller etc. The resulting thing had a couple of K of RAM because RAM was so damn expensive.
Certainly if you want to make something vanishingly small and cheap, especially if you want to make a lot of them then you might use that 30c MCU and JS is not in the running.
Comments
ie a Real that has 32b mantissa, so can do 32 boolean ops, and it also solves the 24b precision floor issue with 32b Reals, (that, I have run into ).
Some portion 50~100% of the other 32 bits are used for exponent. Can be selected for speed.
This 32b mantissa should allow some mathops for mantissa multiply.
Some 64b normalize and shift operations would still be needed.
Such a 'tweaked real' could be quite useful in other languages too.
The use of a format like this would only be for performance reasons. PropGCC already supports 64 bit IEEE doubles, but they're not particularly fast.
Sounds worth exploring.
I guess a benefit of a 64b IEEE subset is things like printf could be used (ie C code could access variables created using the optimized Float )
Was only a little grouchy, just surprised to check back in and find a full blown discussion starting that seemed to be another potential delay. I thought we were all wrapping up with USB/SmartPins done, and boot sequence the last mile...
Nearly....
I think USB test coverage is still not complete, and all smart pin modes are not test-covered either ?
Boot is looking close, and some P2 software is even coming along...
I like the look of ersmith's FastSpin - for P2 and P1
http://forums.parallax.com/discussion/164187/fastspin-compiler-for-p2/p1
Surely if the P2 is to ever gain any sort of commercial acceptance it, and the supplied languages, need to be fully compliant with 'standards'?
Best thing about standards is there are so many to choose from.
dp
@Eric,
Your suggestions make a lot of sense. Particularly "...same structure as a 64 bit IEEE double but with only 32 significant bits"
I'm not really into the idea as potentially it's a lot of work to make it work. Creating a whole new float format and perhaps tweaking any JS engine to use odd sized numbers. And at the end of the day would it be significantly faster in an overall program?
Indeed.
I think the focus of the conversation has blurred a bit. I believe Heater was asking whether we could take advantage of the CORDIC engine to get somewhat-faster-than-typical software support for 64-bit floats. People instead focused on the fact that he said "JavaScript". But I think the question has merit independently of programming language. 32-bit and 64-bit floats are common occurrences in software, so efficiently supporting them is a worthwhile endeavor.
For instance, at one point, I vaguely recall that you could have up to two (or was it three?) operations from the same cog semi-concurrently working through the CORDIC engine. Can we take advantage of that feature to partition the floating-point math in such a way that multiple parts of the same floating point operation can be worked on "at the same time"? And would this be any faster than the traditional software approaches that already exist?
Acceptance by whom, and for what? There are a hundred billion microcontrollers in this world that don't implement 64-bit floating point operations in hardware.
He was speaking toward the use of standard floating point formats, not whether the propeller should have a FPU.
Yeah, the conversation has been blurred by a couple of things.
First is the loathing of anything Javascript by many. That's OK. It's normal language war stuff.
Second is my aside about a 64 bit Propeller. Well, it was an "aside", clearly marked as such. Not a call for a change to 64 bit now.
Yes, I was fishing for a way to use CORDIC to help with software that implements 64 bit floats. Turns out this is not viable. So that's it.
@Chip, Yep. That is where we are. Same as any other 32 bit processor that may or may not have a MUL instruction to help.
Why not? You could use the CORDIC to help with a 64x64 multiply by having it do three of the 32x32 multiplies at once, and while you're waiting to queue each operation and to receive each result, you could do the other 32x32 multiply by using the 16x16 MUL instruction four times. This would probably be faster than the non-CORDIC alternative of just using MUL 16 times.
I have no idea "Why not". Clearly I'm not up to speed on what can be done with the CORDIC engine. Especially in parallel.
Now, I'm not about to start trying to create a IEEE 754 compliant floating point library, using CORDIC or not.
So, if anything happens with JS at all it will depend on a C++ compiler with 64 bit float support. GCC and others can provide that in software using integer ops, ADD, SHIFT, etc. Or presumably making use of a normal MUL instruction if there is one.
Given the bottle neck here, this probably needs at least one COG dedicated as a JS-FPU.
I think we can all agree with you the heinous state of the web. That is web browsers. What with all the links to advertising, code being pulled in from all kind of places we did not order, pop-ups, auto playing videos, tracking this, spying on that. Security is a mess. From a developer perspective the entire browser platform is hideous, with it's babel of synataxes: HTML, CSS, JS, SVG etc, all mixed up.
But I don't think it's the fault of Javascript as such. Although for sure it can help people with all those hideous practices.
Tracking, spying, browser (hence user) profiling, animations, and so on can all be done without Javascript. Ever hear of "web bugs"? https://en.wikipedia.org/wiki/Web_beacon
Certainly all those sites that depend on ad revenue have an easy time. All they have to do is put some links into the pages they serve. The advertisers do the rest via the JS pulled from those links. BUT if we all stopped using JS tomorrow they would find a way around it. All they have to do is get the sites to run software on their servers that injects the advertising/tracking material into the HTML they are serving. Facebook is already working on this because of the popularity of adblock.
Also remember that back in the day it was Java that was supposed to do all of this in the browser. At least that was the Sun Netscape deal. So you should find Java pretty loathsome to.
Then there was MS with it's "Active" whatever system. That makes Visual Basic loathsome. Not to mention all the other languages that "Active" whatever could be used with.
Then there is Google with it's Native Client idea. With that C/C++ and whatever can be compiled can be used in the browser. That would make all those languages loathsome.
Basically you are blaming the son (JS) for the sins of the father (the browser platform).
It's the browser that makes all this mess possible. For example: When I go to a web site that I trust a bit, say forums.parallax.com, how come my browser ends up talking to http://www.gravatar.com/avatar.php? and fetching script from "https://connect.facebook.net/en_US/all.js#xfbml=1" whom I don't trust at all, especially the latter. How come my browser allows that? How come there is no way I can disallow it?
Meanwhile, JS is a language like any other. JS in the browser allows us to do many wonderful things that cannot be done without. JS stand alone is a great programming language for systems, hardware and software, large and small.
Yay Javascript
In the Microcontroller / embedded space, small starts at 1~2k, and even though that is moving up*, it is not moving up quickly enough yet, for inefficient languages.
* I can now get, for sub 30c, an 8 bit MCU with 16k of Flash.
That is enough to manage 32b Float / 32b int, in mature, efficient Compilers like C, Pascal, Modula-2 or Basic.
Five years ago, smallest MCUs pretty much had to be coded only in Assembler.
Now, 16k for sub 30c is a new 2016 point, so who knows what the 'small' will be in 5 years...
Oh yes. For sufficiently large values of "small"
I started out in the era when great big DIP packages held 8 bit micro-processors. To which you had to add RAM and ROM, and all kind of support chips, timer, UART, PIO, interrupt controller etc. The resulting thing had a couple of K of RAM because RAM was so damn expensive.
So, from my perspective, this is amazingly small and cheap: http://www.espruino.com/Pico or this: http://forum.espruino.com/conversations/289540/ or even this: https://www.raspberrypi.org/blog/raspberry-pi-zero/ However they are quite capable of running JS. Thus enabling a lot of people to have fun with micro-controllers, and do useful stuff, without a huge investment of time and effort.
Certainly if you want to make something vanishingly small and cheap, especially if you want to make a lot of them then you might use that 30c MCU and JS is not in the running.
"Embedded" does not mean small.