Here is a different way of achieving 11-bit addresses in the PX...
Remove the CCCC bits and extend the S & D by 2 bits each.
Now, we would require a "fast single clock" instruction to precede instruction(s) that require CCCC testing (ie if_xxx).
COND #%cccc_nn
cccc = condition to test for in the following instructions
nn = the number of following instructions to test for this condition (max 15/16)
This sounds like an excellent idea! Since most instructions are not conditional, requiring a prefix for the few that are doesn't seem like a big price to pay. Nice idea!
Edit: Well, maybe not. Couldn't the same effect be achieved with a conditional relative branch that would just branch around the non-conditional instruction?
These fields are needed in each instruction for deterministic behavior regardless of the condition. Sure they will work with a prefix but one of the main strengths of the Propeller chip is its deterministic instruction set hence realtime operation. Otherwise I would be in favor of a simple "set condition" instruction but that is normally what JZ JNZ JC JNC types of instructions are for.
Here is a different way of achieving 11-bit addresses in the PX...
Remove the CCCC and extend the S & D by 2 bits each.
Now, we would require a "fast single clock" instruction to precede instruction(s) that require CCCC testing (ie if_xxx).
COND #%cccc_nn
cccc = condition to test for in the following instructions
nn = the number of following instructions to test for this condition (max 15/16)
This sounds like an excellent idea! Since most instructions are not conditional, requiring a prefix for the few that are doesn't seem like a big price to pay. Nice idea!
Edit: Well, maybe not. Couldn't the same effect be achieved with a conditional relative branch that would just branch around the non-conditional instruction?
Yes, but you want to avoid pipeline flushes. This is especially the case for hub exec mode, where a branch would cause the instruction streamer to be flushed as well.
I kind of like his suggestion. I'd extend it slightly, though: #%cccc_mmm_nnn
cccc: if_x
mmm: apply cccc to next 0-7 instructions
nnn: apply not(cccc) to next 0-7 instructions after mmm
This allows for small if/else blocks without branching. And, since d/s would now be 11 bits, you'd still have a bit to spare.
Here is a different way of achieving 11-bit addresses in the PX...
Remove the CCCC and extend the S & D by 2 bits each.
Now, we would require a "fast single clock" instruction to precede instruction(s) that require CCCC testing (ie if_xxx).
COND #%cccc_nn
cccc = condition to test for in the following instructions
nn = the number of following instructions to test for this condition (max 15/16)
This sounds like an excellent idea! Since most instructions are not conditional, requiring a prefix for the few that are doesn't seem like a big price to pay. Nice idea!
Edit: Well, maybe not. Couldn't the same effect be achieved with a conditional relative branch that would just branch around the non-conditional instruction?
Yes, but you want to avoid pipeline flushes. This is especially the case for hub exec mode, where a branch would cause the instruction streamer to be flushed as well.
I kind of like his suggestion. I'd extend it slightly, though: #%cccc_mmm_nnn
cccc: if_x
mmm: apply cccc to next 0-7 instructions
nnn: apply not(cccc) to next 0-7 instructions after mmm
This allows for small if/else blocks without branching. And, since d/s would now be 11 bits, you'd still have a bit to spare.
I very often find myself if_'ing only one or two instructions at a time.
My favorite thing about PASM is the fact that every instruction has its own CCCC and CZ bits. You never have to worry about accidentally clobbering flags, and you can branch and still have deterministic timing (and, on the P2, no hubexec FIFO stalls!). I can't imagine P2 hubexec, or P3 hubexec, for that matter, since all of the cogs will still have to fight over the hub, being practical without CCCC bits in each instruction, due to streamer stalls.
Here is a different way of achieving 11-bit addresses in the PX...
Remove the CCCC and extend the S & D by 2 bits each.
Now, we would require a "fast single clock" instruction to precede instruction(s) that require CCCC testing (ie if_xxx).
COND #%cccc_nn
cccc = condition to test for in the following instructions
nn = the number of following instructions to test for this condition (max 15/16)
This sounds like an excellent idea! Since most instructions are not conditional, requiring a prefix for the few that are doesn't seem like a big price to pay. Nice idea!
Edit: Well, maybe not. Couldn't the same effect be achieved with a conditional relative branch that would just branch around the non-conditional instruction?
Yes, but you want to avoid pipeline flushes. This is especially the case for hub exec mode, where a branch would cause the instruction streamer to be flushed as well.
I kind of like his suggestion. I'd extend it slightly, though: #%cccc_mmm_nnn
cccc: if_x
mmm: apply cccc to next 0-7 instructions
nnn: apply not(cccc) to next 0-7 instructions after mmm
This allows for small if/else blocks without branching. And, since d/s would now be 11 bits, you'd still have a bit to spare.
I had actually thought about extending it like...
COND #%cccc_nnn__cccc_nnn
where you could specify up to 2 conditions - uses rightmost set first.
I think "nnn" as 0-7 would be fine.
This would require 14 bits which would be easy to find an available instruction slot.
I was anticipating that the instruction could be a single cycle since it only needs to fetch the instruction as the operands are embedded.
It would be fully deterministic as no jumps are being done - just instructions being nops.
A different way could be...
CC is reduced to 2 bits with 2 bits to extend S & D by 1 bit to 10-bits each (4KB long addressing)
where...
CC=00 = NOP
CC=11 = ALWAYS
CC=01 = FALSE (if_false)
CC=10 =TRUE (if_true)
and a new instruction to set the new TRUE/FALSE flag as follows
SETCOND #cccc 'set TRUE if cccc is met, else set FALSE
Good ideas. For now, we'll keep what we have. I've found that 512 longs is quite sufficient for most everything. Those programs that take more than 512 take so long to write, that there haven't been many of them, for me.
64 bits in the future would allow for plenty of conditional bits per instruction, though.
In the future, everything important will be different. To reach the future, we have to have a P][ and should omit any distraction, please. Let us focus on the toolchain for P][ and it seems to me a good idea to invest some time in exploring Tachyon. My impression is, Peter wants to be asked to present a solution, so we just have to ask the question. What, as we know, is the more difficult task!
A while ago Chip expressed interest in getting a tiny Javascript engine running on the P2.
Sigh, are we going to go through the sausage making circle again?
How about we just get the P2/P16 done, not fly off on yet another tangent, and see if it sells enough to warrant future investment in P3?
If there is a compelling business need for additional 64 bit Cordic work, then sure. Otherwise, I think a 'tweaked' 32b Javascript or maybe some special library hooks or somesuch might be a better idea. Seems like a waste of time and resources to all of a sudden come to the conclusion that JS support is now a leading requirement.
One month people are arguing "Ship It!", the next it 'Oh Shiny!"...
A while ago Chip expressed interest in getting a tiny Javascript engine running on the P2.
Sigh, are we going to go through the sausage making circle again?
How about we just get the P2/P16 done, not fly off on yet another tangent, and see if it sells enough to warrant future investment in P3?
If there is a compelling business need for additional 64 bit Cordic work, then sure. Otherwise, I think a 'tweaked' 32b Javascript or maybe some special library hooks or somesuch might be a better idea. Seems like a waste of time and resources to all of a sudden come to the conclusion that JS support is now a leading requirement.
One month people are arguing "Ship It!", the next it 'Oh Shiny!"...
/grouchy
I might have been having a spell of "keeping up with the Jones'" there. Things change so fast these days that I often doubt my instincts.
Certainly you have your hands full getting the P2 perfected, tested, debugged and out the door. Then there is details like loaders and Spin to be perfected for the P2. Then, probably, there will be help needed on getting C/C++ working efficiently. Then there will need to be a ton of neat P2 objects written to show people what can be done and how. Then....and eventually the P3 to think about
If any of us crazy Jones' want JS on the P2 and it turns out to be even slightly realistic then we can get on with that ourselves.
Aside: It would be neat if any demo code created for the P2 in PASM would be usable from any language not just Spin. That is not to have any tight linkage with Spin code. Given that the Propeller concept is to create drivers and such in software rather than being baked into silicon then those drivers should be usable from any high level language.
Aside: It would be neat if any demo code created for the P2 in PASM would be usable from any language not just Spin. That is not to have any tight linkage with Spin code. Given that the Propeller concept is to create drivers and such in software rather than being baked into silicon then those drivers should be usable from any high level language.
I would argue that, with Spin2Cpp, this isn't such a problem. Especially now that it has a Spin -> PASM LMM translator.
I have a hard time imagining using floating-point types for maintaining bit masks.
You have hit on an interesting Javascript quirk there.
As far as I understand the story, when Brendan Eich was designing JS he wanted to create a language like Self. The powers that be at Netscape said "No, you make it look like C/Java, that's what people will accept". So we have JS, the sophistication of Self wrapped in the syntax of C. So while Brendan was stuffing all the C operators into the language he wondered what to do about the logical operators. They make no sense for real numbers as you point out. Brendan could have just left them out. Rather he decided that a logical operator will take the floats, chop them down to 32 bit integers, do the operation and return a 32 bit integer result. All be it in a new float.
This is a feature that lay unknown and un-noticed for years. Some would say it's yet another example of Javascript's type coercion madness.
As it turns out this was a stroke of genius on Brendan's part. In recent years this logical operator behavior has become very important for those using node.js. And it means one can compile C code to efficient Javascript. When you are working with logical operators modern JS engines can optimize that to integer ops.
As it happens I was today translating a pile old C code to JS today. It parses binary packets and uses a lot of logical operations. For example this is some of the orginal C:
I think you'd be more likely to use arrays. Admittedly, it's not as efficient, but I think we all agree that this isn't necessarily what's important to someone who wants to use JavaScript.
Whilst I'm prepared to sacrifice some run time efficiency for speedy and easy development performance is always important. I fully expect the finished process that the above code will live in to be comparable to the original C in performance.
I'm not quite following. I don't see how you can effectively use the CORDIC engine with a 64-bit float.
We just have to create the float ops in a library that implements them using integer ops. Like any processor without an FPU. The CORDIC at least gives a speed up for those integer multiplies.
...notice how you now painted yourself into a corner, by discarding silicon you have paid for, that can give much higher speed, simply because of constraints self-imposed by poor language choice.
I'm not sure what you mean there. Personally I'm in no corner. I can break out the C/C++ compiler if I feel the need for speed. Then there is always assembler.
Like any device, if the instructions it provides don't do what you want you can always use others, even at a loss of performance.
A self-imposed constraint perhaps. It's only a poor language choice if it does not allow one to do what one wants or makes it excessively difficult to do so.
Cool, got any links to code that uses/demands 2 to the power 52 integers ?
Not off the top of my head. However sometimes you want to count past 4 billion. It helps when working with dates. 32 bit OpenSSL had problems with dates past 2038 because of it's use 32 bit integers.
...and cannot fathom why anyone would choose to fence that [The P2 32 bit CORDIC] off ?
Who said we would? One can write a 64 bit float library using 32 bit integer arithmetic and the CORDI will accelerate the muls and divs there.
Still, as you admitted before, you can always keep adding more languages to the mix, to Fix the Compromises you first imposed. Of course, the original purity is long gone, & the system is then a long way from beginner-friendly.
Those novice programmers are not supposed to see C/C++ or other languages. They power up the device and talk to it in JS. Just like the beginners did back in the 1980's with BASIC on their C64s and such.
I found some JS discussions, where they admitted it was much slower then Micro Python.
Do you have a link to that?
Anyway, don't care. Python does not light my fire.
So, Heater is actually wanting just the CORDIC to be bigger. And not even 64 bit! That's probably viable even now. There is still silicon space if I'm not mistaken and it's not like adding more bits would be hard to do.
Yes, that was my vague idea in my original question.
Turns out it not practical. On reflection I don't think it would help much with JS performance over all anyway.
Javascript is a rubbish language anyway IMHO.
That's an opinion. My opinion is that JS is an elegant and sophisticated language.
It's the main problem destroying the web. It needs banned from web browsers for sure.
This is almost certainly not the fault of JS the language. They could have put almost any language into web pages and the web would still have all the problems it has today.
These problems lie in the whole design of the HTTP, HTML and other protocols. They lie in the browser API, the DOM. And so on. It's a horrible mess.
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.
... So while Brendan was stuffing all the C operators into the language he wondered what to do about the logical operators. They make no sense for real numbers as you point out. Brendan could have just left them out. Rather he decided that a logical operator will take the floats, chop them down to 32 bit integers, do the operation and return a 32 bit integer result. All be it in a new float.
This is a feature that lay unknown and un-noticed for years. Some would say it's yet another example of Javascript's type coercion madness.
As it turns out this was a stroke of genius on Brendan's part.
Is this really limited to 32 bits ?
Above, you were promoting the JS real, as able to manage 52b integers ?
JS uses 64 bit floats. 64 bit floats have a 52 bit mantissa and a sign bit. So one do arithmetic on precise signed integers of effectively 53 bits. Want to count to 9,007,199,254,740,992 no problem.
However, get into logical operators, |, &, >>, <<, etc and things get chopped down to 32 bits as noted above.
This is almost certainly not the fault of JS the language. They could have put almost any language into web pages and the web would still have all the problems it has today.
These problems lie in the whole design of the HTTP, HTML and other protocols. They lie in the browser API, the DOM. And so on. It's a horrible mess.
It's the main problem destroying the web. It needs banned from web browsers for sure.
This is almost certainly not the fault of JS the language. They could have put almost any language into web pages and the web would still have all the problems it has today.
Adding scripting to client side web browsing is fatal. Javascript only exists to be a web browser scripting language. Any subsequent popularity is just momentum from the browsers' use.
Javascript only exists to be a web browser scripting language.
That is not actually the case. Javascript, A.K.A Mocha then Livescript, was intended by Netscape to be used on the server as well.
Any subsequent popularity is just momentum from the browsers' use.
Certainly becoming widespread in the browser meant that there were many users willing to give it a go on the server, in node.js for example. I believe however that JS holds its own as a language in it's own right.
Adding scripting to client side web browsing is fatal.
I presume you mean from a security point of view.
This argument also applies to Java then. That has been a security nightmare for ages.
But wait, PC platforms have been a security nightmare for decades even without JS or Java. All those thousands of vulnerabilities, viruses, trojans doing their work in applications written in C, C++, Pascal, whatever. A classic example is Stuxnet, which got in even without a network connection.
Why have that artificial imposed limit, if the real can manage 52-53 bits ?
Not sure but my guess is that it makes no sense to apply bit-wise logical operators to real numbers. So one has to convert the numbers to integers first. One could use all 52 bits and put them into a 64 bit word then do the ops, but that is messy conceptually and messy to do on the 32 bit machines of the day. Chopping to 32 bits is a good choice for speed. Do we miss not being able to do bit-wise ops on strings of 64 bits?
On intel x86 architecture 64bit floats are held in floating point registers. You can't do bitwise shift/etc. ops on those registers.
Moving them to normal registers for bitwise ops means going to 32bit unless you are in x64 native land.
... was intended by Netscape to be used on the server as well.
Which didn't happen for a decade or so. Not that that matters, it was the browser side that was the problem all along - Even before it became popular for browsers. That fact that it got baked into browsers was the fatal decision. That makes it the non-started as a language.
Adding scripting to client side web browsing is fatal.
I presume you mean from a security point of view.
No, functional. Pushing is the main problem. It changes the Web from a clean file linking system to just another layer of unfettered corporate greed.
Just as an aside: while technically JavaScript may require IEEE 64 bit floats, it seems that a floating point format with a 32 bit significand and 16 bit (or 32 bit) exponent would work in practice. Such a floating point format could be accelerated with the existing P2 instructions, I think.
Just as an aside: while technically JavaScript may require IEEE 64 bit floats, it seems that a floating point format with a 32 bit significand and 16 bit (or 32 bit) exponent would work in practice. Such a floating point format could be accelerated with the existing P2 instructions, I think.
Good idea, but subset precision has already been suggested, and the replies underline why strict adherence to JS is a (very) poor fit on a P2.
64b ops on a P2 will be similar to 32b ops on a 8 bit MCU.
ie Lots of chained-shifts and 64b loops, and s-l-o-w in the extreme.
A float sliced differently to IEEE is a good idea for speed, but it would need a conversion to/from IEEE for numeric export, and I would expect such exports would be common to more powerful hosts.
It may be possible to use a few bits in the exponent as flags to speed operations & test more.
As you hint, 16+ is ok, so 24 would leave 8 flags.
(was there an earlier thread about other than IEEE floats ?)
It does not work Eric. A 64 bit float allows for precise integer values of 52/53 bits. Chopping that down breaks things.
Yes, we couldn't achieve strict JavaScript compatibility with a modified float format. In practice though a version which supported only 32 bit integers would allow an interesting (and I suspect substantial) subset of JS programs to run. How many programs that are of interest on an embedded platform really need more than 32 bits of integer (but less than 52 bits)?
JS with 32 bit floats (i.e. 24 bit integers) probably is a non-starter, since Prop registers are 32 bits.
Do you mean a version of JS that supported only 32 bit integers, no floats at all ?
I don't see that working at all. It breaks too many things:
> 0/0
NaN // How are we to represent the floating point "Not A Number" with only integers?
> 1/0
Infinity // Same for float infinity
> 1.3 + 1.5
2.8 // How would we handle rounding?
32 bit floats should be doable. The C compilers will handle that. But, I think Gordon Williams tried that with his Espruino engine and it broke to many things.
Bottom line, for me anyway, is that if GCC or Clang or whatever does not support 64 bit floats in software so that a JS engine can be compiled nicely then I give up !
Comments
These fields are needed in each instruction for deterministic behavior regardless of the condition. Sure they will work with a prefix but one of the main strengths of the Propeller chip is its deterministic instruction set hence realtime operation. Otherwise I would be in favor of a simple "set condition" instruction but that is normally what JZ JNZ JC JNC types of instructions are for.
Yes, but you want to avoid pipeline flushes. This is especially the case for hub exec mode, where a branch would cause the instruction streamer to be flushed as well.
I kind of like his suggestion. I'd extend it slightly, though: #%cccc_mmm_nnn
cccc: if_x
mmm: apply cccc to next 0-7 instructions
nnn: apply not(cccc) to next 0-7 instructions after mmm
This allows for small if/else blocks without branching. And, since d/s would now be 11 bits, you'd still have a bit to spare.
I very often find myself if_'ing only one or two instructions at a time.
My favorite thing about PASM is the fact that every instruction has its own CCCC and CZ bits. You never have to worry about accidentally clobbering flags, and you can branch and still have deterministic timing (and, on the P2, no hubexec FIFO stalls!). I can't imagine P2 hubexec, or P3 hubexec, for that matter, since all of the cogs will still have to fight over the hub, being practical without CCCC bits in each instruction, due to streamer stalls.
I had actually thought about extending it like...
COND #%cccc_nnn__cccc_nnn
where you could specify up to 2 conditions - uses rightmost set first.
I think "nnn" as 0-7 would be fine.
This would require 14 bits which would be easy to find an available instruction slot.
I was anticipating that the instruction could be a single cycle since it only needs to fetch the instruction as the operands are embedded.
It would be fully deterministic as no jumps are being done - just instructions being nops.
A different way could be...
CC is reduced to 2 bits with 2 bits to extend S & D by 1 bit to 10-bits each (4KB long addressing)
where...
CC=00 = NOP
CC=11 = ALWAYS
CC=01 = FALSE (if_false)
CC=10 =TRUE (if_true)
and a new instruction to set the new TRUE/FALSE flag as follows
SETCOND #cccc 'set TRUE if cccc is met, else set FALSE
64 bits in the future would allow for plenty of conditional bits per instruction, though.
Sigh, are we going to go through the sausage making circle again?
How about we just get the P2/P16 done, not fly off on yet another tangent, and see if it sells enough to warrant future investment in P3?
If there is a compelling business need for additional 64 bit Cordic work, then sure. Otherwise, I think a 'tweaked' 32b Javascript or maybe some special library hooks or somesuch might be a better idea. Seems like a waste of time and resources to all of a sudden come to the conclusion that JS support is now a leading requirement.
One month people are arguing "Ship It!", the next it 'Oh Shiny!"...
/grouchy
I might have been having a spell of "keeping up with the Jones'" there. Things change so fast these days that I often doubt my instincts.
Certainly you have your hands full getting the P2 perfected, tested, debugged and out the door. Then there is details like loaders and Spin to be perfected for the P2. Then, probably, there will be help needed on getting C/C++ working efficiently. Then there will need to be a ton of neat P2 objects written to show people what can be done and how. Then....and eventually the P3 to think about
If any of us crazy Jones' want JS on the P2 and it turns out to be even slightly realistic then we can get on with that ourselves.
Aside: It would be neat if any demo code created for the P2 in PASM would be usable from any language not just Spin. That is not to have any tight linkage with Spin code. Given that the Propeller concept is to create drivers and such in software rather than being baked into silicon then those drivers should be usable from any high level language.
I would argue that, with Spin2Cpp, this isn't such a problem. Especially now that it has a Spin -> PASM LMM translator.
As far as I understand the story, when Brendan Eich was designing JS he wanted to create a language like Self. The powers that be at Netscape said "No, you make it look like C/Java, that's what people will accept". So we have JS, the sophistication of Self wrapped in the syntax of C. So while Brendan was stuffing all the C operators into the language he wondered what to do about the logical operators. They make no sense for real numbers as you point out. Brendan could have just left them out. Rather he decided that a logical operator will take the floats, chop them down to 32 bit integers, do the operation and return a 32 bit integer result. All be it in a new float.
This is a feature that lay unknown and un-noticed for years. Some would say it's yet another example of Javascript's type coercion madness.
As it turns out this was a stroke of genius on Brendan's part. In recent years this logical operator behavior has become very important for those using node.js. And it means one can compile C code to efficient Javascript. When you are working with logical operators modern JS engines can optimize that to integer ops.
As it happens I was today translating a pile old C code to JS today. It parses binary packets and uses a lot of logical operations. For example this is some of the orginal C: And this is the Javascript version: Whilst I'm prepared to sacrifice some run time efficiency for speedy and easy development performance is always important. I fully expect the finished process that the above code will live in to be comparable to the original C in performance. We just have to create the float ops in a library that implements them using integer ops. Like any processor without an FPU. The CORDIC at least gives a speed up for those integer multiplies.
Like any device, if the instructions it provides don't do what you want you can always use others, even at a loss of performance.
A self-imposed constraint perhaps. It's only a poor language choice if it does not allow one to do what one wants or makes it excessively difficult to do so. Not off the top of my head. However sometimes you want to count past 4 billion. It helps when working with dates. 32 bit OpenSSL had problems with dates past 2038 because of it's use 32 bit integers. Who said we would? One can write a 64 bit float library using 32 bit integer arithmetic and the CORDI will accelerate the muls and divs there. Those novice programmers are not supposed to see C/C++ or other languages. They power up the device and talk to it in JS. Just like the beginners did back in the 1980's with BASIC on their C64s and such. Do you have a link to that?
Anyway, don't care. Python does not light my fire.
Turns out it not practical. On reflection I don't think it would help much with JS performance over all anyway. That's an opinion. My opinion is that JS is an elegant and sophisticated language. This is almost certainly not the fault of JS the language. They could have put almost any language into web pages and the web would still have all the problems it has today.
These problems lie in the whole design of the HTTP, HTML and other protocols. They lie in the browser API, the DOM. And so on. It's a horrible mess.
My 64 bit Propeller statement was only an aside.
I'm with you. I want a P2 ASAP.
Is this really limited to 32 bits ?
Above, you were promoting the JS real, as able to manage 52b integers ?
However, get into logical operators, |, &, >>, <<, etc and things get chopped down to 32 bits as noted above.
Have you confirmed that is actually done ?
Why have that artificial imposed limit, if the real can manage 52-53 bits ?
Oh AMEN to this my brother in JS and DOM hell
So, Javascript is a rubbish language.
This argument also applies to Java then. That has been a security nightmare for ages.
But wait, PC platforms have been a security nightmare for decades even without JS or Java. All those thousands of vulnerabilities, viruses, trojans doing their work in applications written in C, C++, Pascal, whatever. A classic example is Stuxnet, which got in even without a network connection. That is a non-sequitur.
Moving them to normal registers for bitwise ops means going to 32bit unless you are in x64 native land.
No, functional. Pushing is the main problem. It changes the Web from a clean file linking system to just another layer of unfettered corporate greed.
64 bit floats can of course be implemented with 32 bit integer ops,even without a hardware multiply.
I have no idea if having a 32 bit MUL instruction or CORDIC assistance helps with that. Just guessing it might.
64b ops on a P2 will be similar to 32b ops on a 8 bit MCU.
ie Lots of chained-shifts and 64b loops, and s-l-o-w in the extreme.
A float sliced differently to IEEE is a good idea for speed, but it would need a conversion to/from IEEE for numeric export, and I would expect such exports would be common to more powerful hosts.
It may be possible to use a few bits in the exponent as flags to speed operations & test more.
As you hint, 16+ is ok, so 24 would leave 8 flags.
(was there an earlier thread about other than IEEE floats ?)
Addit: Here is unum... seems already has a Python port.
http://motherboard.vice.com/read/a-new-number-format-for-computers-could-nuke-approximation-errors-for-good
I also find suggestions some are working to fix this shortcoming in JS eg this link
https://blog.mozilla.org/javascript/2013/11/07/efficient-float32-arithmetic-in-javascript/
talks about 32b floats, and how new libs allow 32b with good gains in speed on MPUs
JS with 32 bit floats (i.e. 24 bit integers) probably is a non-starter, since Prop registers are 32 bits.
http://www.jhauser.us/arithmetic/SoftFloat.html
Do you mean a version of JS that supported only 32 bit integers, no floats at all ?
I don't see that working at all. It breaks too many things:
32 bit floats should be doable. The C compilers will handle that. But, I think Gordon Williams tried that with his Espruino engine and it broke to many things.
Bottom line, for me anyway, is that if GCC or Clang or whatever does not support 64 bit floats in software so that a JS engine can be compiled nicely then I give up !