It's odd they have the Zync chip. But I guess that is a cool device to have in their educational circles. Linux running core and FPGA, what more could you want?
Except my Zync board has a 16 core floating point Epiphany processor on it as well...
DIP is a dying niche in actual production systems, but certainly not in the hobbyist 'maker' world where Arduino etc. live.
I'd pay decent money for a DIP-64 version of the Prop 1 with an additional 24 pins of I/O on OUTB, and throw in a bit more HUB RAM, up the clock to 100mhz or so, and make it 5v tolerant. Just a small incremental improvement on the Prop 1, and it would sell well to 'maker' types, especially now that there's proper GCC support for the Prop and Parallax isn't trying to flog the proprietary SPIN anymore.
It's odd they have the Zync chip. But I guess that is a cool device to have in their educational circles. Linux running core and FPGA, what more could you want?
Except my Zync board has a 16 core floating point Epiphany processor on it as well...
Does the Epiphany board have a big enough Zync to run the P1V RTL? What about a RISC V core?
What's decent money? $15 $25, more? It would need to pay for all its engineering, fab and support costs based on a small volume. Boutique chips sound cool but would be expensive.
What's decent money? $15 $25, more? It would need to pay for all its engineering, fab and support costs based on a small volume. Boutique chips sound cool but would be expensive.
Yeah fair enough. I could see paying $20-$25 basically double the cost of the existing P1. But yes, I'm sure the economics don't work out for them otherwise they'd be doing it already. Though now with the Verilog done and out there maybe it's easier for them to make this happen than before? In any case, the P2 sounds interesting if we ever see it. But I'm just the very bottom of the hobbyist segment, a tinkerer.
He seems to have disappeared. I invested in his Indiegogo project but haven't heard anything since. He said he would send me a board before Christmas but it never arrived and he doesn't return PMs.
Remember that one of the major reasons for Chip & Ken to do the P1 development was their experience with Scenix and Microchip over the SX patent fight. Chip wanted for Parallax to have their own IP that they could count on for the long timelines they believe in and support for their core products (and are important in the educational and hobby market).
And you know how successful they have been at gaining mind share and shipping millions of units.
You missed one, the Arduino.
Between the Arduino and the Pi, I believe the educational market is relatively sewn up.
Again between that, and the very limited industrial take-up, its hard to see where Parallax is going to be able to grow or even retain marketshare. Just saw an ST M4 (7?) with a co-M0+ minion, and I don't doubt that we may start seeing more of these along with big.Little octo and greater cores....
Oddly enough, it seems just possible that the world will come around closer to Chip's vision of core/single purpose in spite of itself.
From the Risc V videos I saw, it seems like they have made the design process pretty automated, with some sort of VHDL design compiler that greatly reduces work.
Imagine if Chip were able to take the Risc V on the whole, and use the add-on subsystem capability to add all of his value-add special sauce? And have the design ready from the start at a reasonable fab arch., which could easily be backed out to older 180nm if cost is a concern. Then if there is success, it would be easy to ramp back to the more expensive 65/45nm for speed, lower cost die.
Yes the BS2 line is a relic today. But Parallax let it happen because certain people didn't want to use COTS micros so Banzai with his Arduino stepped in and took over the hobbyist and education market along with the Raspberry. They got the mindshare and market penetration that the Prop can't hope to dent.
Snooze and you loose.
As to your question: Because Chip could, he was actually ahead of his time but the implementation(P-1) is odd and limited in certain respects which hampered it's adoption. The P-2 which should have been out within 4 years of the rollout of the P-1, is just so very late it's going to enter a ecosystem that is now full of multicores. Freescale has multicore PPC controllers, NXP has theirs, Infineon, TI has it's Hercules line of dual core Safety processors. It's all the rage.
Between the Arduino and the Pi, I believe the educational market is relatively sewn up.
Far from it in my view. In fact, the availability of these platforms makes other choices very interesting to them. It's a bold statement but I can see how one could come to that conclusion.
Parallax has about 30+ days of teacher instruction planned through August at this junction. Educators aren't as enticed by a fashion show as we may be. They need a whole system, and that consists of programming tools, hardware, WiFi programming, company staff to answer their questions and replace their hardware, tutorials and robots. That's what we do - they don't want to monkey around with cobbling things together to fill a very valuable 45 minutes of class time. They need the whole system with a lot of trust in their supplier, a rapport that's built over time.
And this equation is now becoming more complex with 1-to-1 schools everywhere. The iPads and Chromebooks must be supported, and we're headed that way. In some way, we could even achieve our goals with a variety of processors. Entire educational programs are started without consideration to architectures and brands in education. Do you think that middle school educators know what processor is in the Lego controllers?
... The iPads and Chromebooks must be supported, and we're headed that way.
From what I can see, Parallax are ahead of the game in Tools-Portability.
The posters over in the AVR forums lament being Windows-only, so they are a long way back from hosting tools on a RaspPi 2.
In some way, we could even achieve our goals with a variety of processors. Entire educational programs are started without consideration to architectures and brands in education. Do you think that middle school educators know what processor is in the Lego controllers?
Ken Gracey
Agreed, but I'm a little puzzled why there is no BS3 planned ?
Seems there is an opening for a 5V compatible, drop in replacement done with Processor XYZ - as you say, they do not care what specific engine runs PBASIC, just that it still runs code they wrote last year.
The choices of Processor XYZ that could do this, are expanding as more vendors grasp that 5V still matters.
Remember that one of the major reasons for Chip & Ken to do the P1 development was their experience with Scenix and Microchip over the SX patent fight. Chip wanted for Parallax to have their own IP that they could count on for the long timelines they believe in and support for their core products (and are important in the educational and hobby market).
Sure, but as Ken says above, that IP is in the Documents and Support infrastructure and customer code - customers care less about the Silicon itself.
There are a lot of choices today for a CPU that could host BS3 - the IP is in the PBASIC.
Agreed, but I'm a little puzzled why there is no BS3 planned ?
We'd love to have a BS3. It poses a few challenges you understand well related to total socket compatibility. Mainly, more I/O pins and voltage levels. A Propeller BS3 badly wants nothing to do with a 24-pin socket.
PropBASIC brings this reality closer to everybody. What if you could program a Propeller on the new Activity Board WX in PropBASIC, having all the nice Propeller I/O hardware available without any stacking boards?
Minor comment on what you suggested above about where we are in the development tools process. I truly believe we're ahead of the others in this way right now. We've got a total of 12 outside engineers working with Jeff to deliver the tools that our customers will need in the near future. Today you can program a Propeller over WiFi on an iPad and soon we'll have Chromebook support. While many of us are happy Windows users, almost all of our efforts exclude Windows (except the one called "continue support in Propeller Tool as an official Parallax software"). Note to Phil: NO, we will not end Propeller Tool support for Windows.
Well, you know how us armchair CEO's can be.. the sky always seems about to fall.
Very good points that go to comments about Parallax as a VAR indeed.
The only issue I have is with the disruptive technology aspect that the Pi seems to be becoming.
The Pi gives them both a computer w/GUI, and decent uC access to GPIO, etc.
The VAR chops Parallax has probably puts the Pi to shame currently. However with such a massive market penetration and the lesson sharing that occurs in the educational system, I think they will quite likely vastly improve their actual educational material.
At some point there is an inflection point.
As long as Parallax is seeing good enough revenue from EDU sales, then thats good.
Its just that for the cash strapped schools the Arduino seems to be worth some hassle if the other option is to do without.
And for the schools that have the cash, some spare/used/donated displays and a dozen or so $5 keyboards and mice, and no need for a central laptop/desktop programming computer seem to make the Pi financially more attractive.
Even more than that though, since it can also double as a computer/programming lab I guess.
A Plan B is useful to have around.
PropBasic is back? How come no one tells me these things!
This is still what could sell the Prop/BS/Stamp!
We'd love to have a BS3. It poses a few challenges you understand well related to total socket compatibility. Mainly, more I/O pins and voltage levels. A Propeller BS3 badly wants nothing to do with a 24-pin socket.
That was why I focused on chips other than Prop for the BS3, 24 pins and 5V are cornerstone requirements to a drop-in replacement.
I'm trying to find out if that 5V Nuvoton part ROM Loader can boot over USB.**
PropBASIC brings this reality closer to everybody. What if you could program a Propeller on the new Activity Board WX in PropBASIC, having all the nice Propeller I/O hardware available without any stacking boards?
Sure, that has appeal but it is less a BS3, than a separate bridge step.
**Addit:
Found info in
NuMicro ISP Programming Tool User Manual EN Rev1 46.pdf
and that says ISP through USB
for any of
MCU family USB Loader Pin to GND
NUC120/140/442/472 Nano100ser PB.15
NUC101 PD.0
NUC122/220 PA.10
NUC123/M451ser PB.14
so any of those parts would be BS3 suitable (except Nano @ 3v3 only)
- becomes a package size question.
and this sounds brave - no carry bit ?! - is going to affect a LOT of things
["RISC-V intentionally lacks condition codes, and even lacks a carry bit.[4] The designers claim that this can simplify CPU designs by minimizing interactions between instructions.[4] Instead RISC-V builds comparison operations into its conditional-jumps.[4] Use of comparisons may slightly increase its power usage in some applications. The lack of a carry bit complicates multiple-precision arithmetic. RISC-V does not detect or flag most arithmetic errors, including overflow, underflow and divide by zero[...]
MIPS (and that would include PIC32) doesn't have a carry bit either.. or even a status register. Much the same thinking I guess. And they're doing fine, clearly. There was a lot of number crunching going on on various SGI computers too, so it must be possible.
I just looked up a stackoverflow question about adding 64-bit numbers on a 32-bit MIPS processor. Seemed simple enough. I was a bit surprised the first time I heard about the 'no carry flag' in the MIPS ISA. When I first started with microprocessors (textbook at school) and later with the 6502 ('Programming the 6502' by Zaks) it seemed essential to have a carry flag. The RISC folks don't seem to agree.
There was a lot of number crunching going on on various SGI computers too, so it must be possible.
MIPS was really fast relative to the system clock. I was running IRIX machines in the 90's and a 400Mhz MIPS R10K regularly outperformed Pentium 3 chips running at up to a Ghz.
Some of that was due to dedicated FPU's on board, well integrated with cache, etc... Another part of the story was the SGI MIPS Pro Compiler. That thing has insane good optimization. SGI optimized the living Smile out of MIPS. Today, that's all been moved to Itanium and Linux, quite an accomplishment given how closely IRIX + MIPS were developed.
Lastly, many of the systems featured large Cache RAM sizes, and great I/O / system throughput on all busses. It took very significant advances in the PC FSB to really set Pentium free.
I was running big apps at the time. High end Mechanical CAD, Alias and Maya, video production, etc... It took Intel getting over 1Ghz and getting Pentium 4 right to really displace higher clock MIPS systems. The last one I ran was a Fuel, R12K @ 600 or 700Mhz, and it spanked at P4 clocked at somewhere around 2Ghz on those tasks.
Once I compiled XMame on both gcc and Mips Pro at full optimization. Gcc built it a bit faster, but the application performance was about 10-20 percent better under Mips Pro. Now, gcc has come a long way. I'm not sure that would be true today, and there are people out there still building on IRIX. Might be fun one day to ask them.
This is part of why I've followed the RISC V efforts. If they do it right, I totally believe they will pull off a high performance, efficient CPU. But, there will have to be a lot of compiler work to maximize it. A lot of that is done, or known however. Maybe it's just work, or the SGI people who did that advanced work can get it done quickly. Many of those engineers are still out there, and on the graphics end of things, nVidia is where they live today. I'm not sure where the compiler group ended up, if anywhere specific.
One good thing is a whole lot of the IRIX attributes are in Linux, or can be added. The scheduler in IRIX is awesome. You can bury one of those boxes and never miss a beat on your I/O and interactive application performance. (given the app is well written) And Linux definitely has the NUMA / multi-cpu, single system image stuff. That all happened in the late 00's on the way to Itanium. Mapped over and done. There have been 2K CPU, NUMA, SGI Linux systems performing very well on Itanium.
If RISC V actually pans out, Linux + RISC + nVidia and some good systems design, leaving the PC / Intel stuff behind could happen, and it would be excellent. Count me in. IRIX was awesome. Best computing experience I ever had, and I ran it all from a single R5K to a NUMA Origin. Good times. We could be rocking in style, just like the 90's again.
Based on those experiences, having a carry flag isn't important. If it were, there would have been some issues, and those machines performed, and did well on even high accuracy big math. (which a lot of them are still running today)
BTW: A 30 Mhz (yes, 30!!) Indigo Elan could play 256Kbps Mp3 files, over the network, while still responding to many GUI operations. That was an R4000, I believe. I used a little program called "amp", compiled with Mips Pro. IRIX 5.3? Or maybe 5.2... don't remember anymore.
Oh I'm sure it is possible - I sometimes code adders deliberately avoiding carry, to save PUSH/POP but the code uses jumps, and is larger and slower code. RISC-V is still playing catch-up on side size.
Add $t2 $t3 + $t4 $t5, result in $t0 $t1
addu $t1, $t3, $t5 # add least significant word
sltu $t0, $t1, $t5 # set carry-in bit
addu $t0, $t0, $t2 # add in first most significant word
addu $t0, $t0, $t4 # add in second most significant word
Doesn't seem so difficult, on MIPS at least. I haven't looked at the RISC V instruction set yet, but it must have something similar to sltu (set on less than unsigned: If $t1 is less than $t5, $t0 is set to one, if not it's set to zero.
(Edit: I checked, and RISC V has the same SLTU instruction, works the same way as above)
@potatohead: I had much the same experience with SGI in the nineties (and even later - installed the last R12k system in 2011!) as you, although my applications were of a different type. Lots of data though. The huge difference between SGI systems and other (e.g. IBM/AIX, or even Sun, or Intel PCs running Linux) long into the 21th century was how much better the SGI systems could handle loads. Lots of processes running at the same time, and nothing stalled.
Add $t2 $t3 + $t4 $t5, result in $t0 $t1
addu $t1, $t3, $t5 # add least significant word
sltu $t0, $t1, $t5 # set carry-in bit
addu $t0, $t0, $t2 # add in first most significant word
addu $t0, $t0, $t4 # add in second most significant word
Doesn't seem so difficult, on MIPS at least. I haven't looked at the RISC V instruction set yet, but it must have something similar to sltu (set on less than unsigned: If $t1 is less than $t5, $t0 is set to one, if not it's set to zero.
(Edit: I checked, and RISC V has the same SLTU instruction, works the same way as above)
Wow, that looks like they had to tip-toe around some patent.
Saved : 1 carry Flag, a single Boolean register.
Cost : Consumes One whole 32 bit register to build a carry on the fly, plus five repeated references in code to that register.
They have not really 'eliminated' the carry flag, just instead created on on the fly.
@Tor: Yeah, good times, and more of them for you it seems! I ran SGI solid until about '04, then I had to step away. I still have one installation out there on Octane running some old CAM software. Uptime is years now. I get to check in on it, from time to time, and it's fine, sitting among a bunch of spares I had them pick up on e-bay. The recovery is all scripted. They can move the little clock chip, slap some disks into another machine, boot, script runs, and go... Who knows how long they will use it?
@jmg, maybe... I suspect it's more about structuring things to move through the pipeline efficiently, and for cache performance / watt more though.
That's 24 bytes of code for Intel and only 16 for RISCV. Looks like Intel consumes 50% more memory bandwidth for code fetching.
Why all the fuss about a missing carry flag. I'm no expert but as far as I can tell compilers generally don't use them. Most 32 bit programs are not doing 64 integer maths very much.
Heck we are moving to a world where 64 bit CPU's will be two a penny. We can already get an 8 core 64 bit ARM board for 130 dollars. Who need the carry bit in that world?
Sadly I don't have a 32 bit Intel system here and I have not figured out how to build a 32 bit RISC-V GCC compiler so I can't see how 32 bit machines would add 64 bit numbers.
Hehe, LMM gives new meaning to the load and store model. Of course in a real situation any local working variables will optimise away and produce much neater looking results.
Comments
It's odd they have the Zync chip. But I guess that is a cool device to have in their educational circles. Linux running core and FPGA, what more could you want?
Except my Zync board has a 16 core floating point Epiphany processor on it as well...
I'd pay decent money for a DIP-64 version of the Prop 1 with an additional 24 pins of I/O on OUTB, and throw in a bit more HUB RAM, up the clock to 100mhz or so, and make it 5v tolerant. Just a small incremental improvement on the Prop 1, and it would sell well to 'maker' types, especially now that there's proper GCC support for the Prop and Parallax isn't trying to flog the proprietary SPIN anymore.
Has anyone done a P1V for the Zynq yet? I don't recall. It would be cool, then you could have a P1V with a tightly coupled 2 core Linux/ARM frontend!
Yeah fair enough. I could see paying $20-$25 basically double the cost of the existing P1. But yes, I'm sure the economics don't work out for them otherwise they'd be doing it already. Though now with the Verilog done and out there maybe it's easier for them to make this happen than before? In any case, the P2 sounds interesting if we ever see it. But I'm just the very bottom of the hobbyist segment, a tinkerer.
Yes, Antti has something in the works..
http://forums.parallax.com/showthread.php/158636-Open-Propeller-Project-Soft-Propeller-40P14?p=1309247&viewfull=1#post1309247
Thanks, jmg, I forgot all about that one! Looks like we're in business!
I dug some more into that, and the only thing missing is USB.
I think a BS3 really needs a USB ...
Alternatives could be something like NUC220 from Nuvoton, 2.5V to 5.5V, and 7mm packages
http://www.nuvoton.com/hq/products/microcontrollers/arm-cortex-m0-mcus/nuc120-122-123-220-usb-series/?__locale=en
Digikey do have a Eval/Debug board, (at something less than a BS2)
http://www.digikey.com/product-detail/en/NUTINY-SDK-NUC220/NUTINY-SDK-NUC220-ND/4271461
The NUC220 mentions a ROM Loader, but I could not nail down if that is USB loader, or just Serial one ?
Possibly Spansion FM3/FM4 may have something, as they are also 5V
You missed one, the Arduino.
Between the Arduino and the Pi, I believe the educational market is relatively sewn up.
Again between that, and the very limited industrial take-up, its hard to see where Parallax is going to be able to grow or even retain marketshare. Just saw an ST M4 (7?) with a co-M0+ minion, and I don't doubt that we may start seeing more of these along with big.Little octo and greater cores....
Oddly enough, it seems just possible that the world will come around closer to Chip's vision of core/single purpose in spite of itself.
From the Risc V videos I saw, it seems like they have made the design process pretty automated, with some sort of VHDL design compiler that greatly reduces work.
Imagine if Chip were able to take the Risc V on the whole, and use the add-on subsystem capability to add all of his value-add special sauce? And have the design ready from the start at a reasonable fab arch., which could easily be backed out to older 180nm if cost is a concern. Then if there is success, it would be easy to ramp back to the more expensive 65/45nm for speed, lower cost die.
If you find yourself in a hole, stop digging.
Yes the BS2 line is a relic today. But Parallax let it happen because certain people didn't want to use COTS micros so Banzai with his Arduino stepped in and took over the hobbyist and education market along with the Raspberry. They got the mindshare and market penetration that the Prop can't hope to dent.
Snooze and you loose.
As to your question: Because Chip could, he was actually ahead of his time but the implementation(P-1) is odd and limited in certain respects which hampered it's adoption. The P-2 which should have been out within 4 years of the rollout of the P-1, is just so very late it's going to enter a ecosystem that is now full of multicores. Freescale has multicore PPC controllers, NXP has theirs, Infineon, TI has it's Hercules line of dual core Safety processors. It's all the rage.
Far from it in my view. In fact, the availability of these platforms makes other choices very interesting to them. It's a bold statement but I can see how one could come to that conclusion.
Parallax has about 30+ days of teacher instruction planned through August at this junction. Educators aren't as enticed by a fashion show as we may be. They need a whole system, and that consists of programming tools, hardware, WiFi programming, company staff to answer their questions and replace their hardware, tutorials and robots. That's what we do - they don't want to monkey around with cobbling things together to fill a very valuable 45 minutes of class time. They need the whole system with a lot of trust in their supplier, a rapport that's built over time.
And this equation is now becoming more complex with 1-to-1 schools everywhere. The iPads and Chromebooks must be supported, and we're headed that way. In some way, we could even achieve our goals with a variety of processors. Entire educational programs are started without consideration to architectures and brands in education. Do you think that middle school educators know what processor is in the Lego controllers?
That's my story and I believe it more every day
Ken Gracey
From what I can see, Parallax are ahead of the game in Tools-Portability.
The posters over in the AVR forums lament being Windows-only, so they are a long way back from hosting tools on a RaspPi 2.
Agreed, but I'm a little puzzled why there is no BS3 planned ?
Seems there is an opening for a 5V compatible, drop in replacement done with Processor XYZ - as you say, they do not care what specific engine runs PBASIC, just that it still runs code they wrote last year.
The choices of Processor XYZ that could do this, are expanding as more vendors grasp that 5V still matters.
There are a lot of choices today for a CPU that could host BS3 - the IP is in the PBASIC.
We'd love to have a BS3. It poses a few challenges you understand well related to total socket compatibility. Mainly, more I/O pins and voltage levels. A Propeller BS3 badly wants nothing to do with a 24-pin socket.
PropBASIC brings this reality closer to everybody. What if you could program a Propeller on the new Activity Board WX in PropBASIC, having all the nice Propeller I/O hardware available without any stacking boards?
Minor comment on what you suggested above about where we are in the development tools process. I truly believe we're ahead of the others in this way right now. We've got a total of 12 outside engineers working with Jeff to deliver the tools that our customers will need in the near future. Today you can program a Propeller over WiFi on an iPad and soon we'll have Chromebook support. While many of us are happy Windows users, almost all of our efforts exclude Windows (except the one called "continue support in Propeller Tool as an official Parallax software"). Note to Phil: NO, we will not end Propeller Tool support for Windows.
Ken Gracey
Well, you know how us armchair CEO's can be.. the sky always seems about to fall.
Very good points that go to comments about Parallax as a VAR indeed.
The only issue I have is with the disruptive technology aspect that the Pi seems to be becoming.
The Pi gives them both a computer w/GUI, and decent uC access to GPIO, etc.
The VAR chops Parallax has probably puts the Pi to shame currently. However with such a massive market penetration and the lesson sharing that occurs in the educational system, I think they will quite likely vastly improve their actual educational material.
At some point there is an inflection point.
As long as Parallax is seeing good enough revenue from EDU sales, then thats good.
Its just that for the cash strapped schools the Arduino seems to be worth some hassle if the other option is to do without.
And for the schools that have the cash, some spare/used/donated displays and a dozen or so $5 keyboards and mice, and no need for a central laptop/desktop programming computer seem to make the Pi financially more attractive.
Even more than that though, since it can also double as a computer/programming lab I guess.
A Plan B is useful to have around.
PropBasic is back? How come no one tells me these things!
This is still what could sell the Prop/BS/Stamp!
I'm trying to find out if that 5V Nuvoton part ROM Loader can boot over USB.**
Sure, that has appeal but it is less a BS3, than a separate bridge step.
**Addit:
Found info in
NuMicro ISP Programming Tool User Manual EN Rev1 46.pdf
and that says
ISP through USB
for any of so any of those parts would be BS3 suitable (except Nano @ 3v3 only)
- becomes a package size question.
I think the 5V Spansion USB parts also have USB loader ability, based on DOCs here
http://www.spansion.com/products/microcontrollers/32-bit-arm-core/fm3/Pages/MB9BF524KPMC-G-JNE2.aspx#inpageTabs=1
I just looked up a stackoverflow question about adding 64-bit numbers on a 32-bit MIPS processor. Seemed simple enough. I was a bit surprised the first time I heard about the 'no carry flag' in the MIPS ISA. When I first started with microprocessors (textbook at school) and later with the 6502 ('Programming the 6502' by Zaks) it seemed essential to have a carry flag. The RISC folks don't seem to agree.
MIPS was really fast relative to the system clock. I was running IRIX machines in the 90's and a 400Mhz MIPS R10K regularly outperformed Pentium 3 chips running at up to a Ghz.
Some of that was due to dedicated FPU's on board, well integrated with cache, etc... Another part of the story was the SGI MIPS Pro Compiler. That thing has insane good optimization. SGI optimized the living Smile out of MIPS. Today, that's all been moved to Itanium and Linux, quite an accomplishment given how closely IRIX + MIPS were developed.
Lastly, many of the systems featured large Cache RAM sizes, and great I/O / system throughput on all busses. It took very significant advances in the PC FSB to really set Pentium free.
I was running big apps at the time. High end Mechanical CAD, Alias and Maya, video production, etc... It took Intel getting over 1Ghz and getting Pentium 4 right to really displace higher clock MIPS systems. The last one I ran was a Fuel, R12K @ 600 or 700Mhz, and it spanked at P4 clocked at somewhere around 2Ghz on those tasks.
Once I compiled XMame on both gcc and Mips Pro at full optimization. Gcc built it a bit faster, but the application performance was about 10-20 percent better under Mips Pro. Now, gcc has come a long way. I'm not sure that would be true today, and there are people out there still building on IRIX. Might be fun one day to ask them.
This is part of why I've followed the RISC V efforts. If they do it right, I totally believe they will pull off a high performance, efficient CPU. But, there will have to be a lot of compiler work to maximize it. A lot of that is done, or known however. Maybe it's just work, or the SGI people who did that advanced work can get it done quickly. Many of those engineers are still out there, and on the graphics end of things, nVidia is where they live today. I'm not sure where the compiler group ended up, if anywhere specific.
One good thing is a whole lot of the IRIX attributes are in Linux, or can be added. The scheduler in IRIX is awesome. You can bury one of those boxes and never miss a beat on your I/O and interactive application performance. (given the app is well written) And Linux definitely has the NUMA / multi-cpu, single system image stuff. That all happened in the late 00's on the way to Itanium. Mapped over and done. There have been 2K CPU, NUMA, SGI Linux systems performing very well on Itanium.
If RISC V actually pans out, Linux + RISC + nVidia and some good systems design, leaving the PC / Intel stuff behind could happen, and it would be excellent. Count me in. IRIX was awesome. Best computing experience I ever had, and I ran it all from a single R5K to a NUMA Origin. Good times.
Based on those experiences, having a carry flag isn't important. If it were, there would have been some issues, and those machines performed, and did well on even high accuracy big math. (which a lot of them are still running today)
BTW: A 30 Mhz (yes, 30!!) Indigo Elan could play 256Kbps Mp3 files, over the network, while still responding to many GUI operations. That was an R4000, I believe. I used a little program called "amp", compiled with Mips Pro.
IMHO, there is very likely to be a modest balance. Won't be the smallest code, but it will run fast and consistently.
(Edit: I checked, and RISC V has the same SLTU instruction, works the same way as above)
@potatohead: I had much the same experience with SGI in the nineties (and even later - installed the last R12k system in 2011!) as you, although my applications were of a different type. Lots of data though. The huge difference between SGI systems and other (e.g. IBM/AIX, or even Sun, or Intel PCs running Linux) long into the 21th century was how much better the SGI systems could handle loads. Lots of processes running at the same time, and nothing stalled.
Wow, that looks like they had to tip-toe around some patent.
Saved : 1 carry Flag, a single Boolean register.
Cost : Consumes One whole 32 bit register to build a carry on the fly, plus five repeated references in code to that register.
They have not really 'eliminated' the carry flag, just instead created on on the fly.
What about arbitrary precision decimal, is there any instruction features for that application in MIPS?
@jmg, maybe... I suspect it's more about structuring things to move through the pipeline efficiently, and for cache performance / watt more though.
Here is how my Intel 64 bit box add integers 2 integers and stores the result: And this is how the RISC V does it: That's 24 bytes of code for Intel and only 16 for RISCV. Looks like Intel consumes 50% more memory bandwidth for code fetching.
Why all the fuss about a missing carry flag. I'm no expert but as far as I can tell compilers generally don't use them. Most 32 bit programs are not doing 64 integer maths very much.
Heck we are moving to a world where 64 bit CPU's will be two a penny. We can already get an 8 core 64 bit ARM board for 130 dollars. Who need the carry bit in that world?
Sadly I don't have a 32 bit Intel system here and I have not figured out how to build a 32 bit RISC-V GCC compiler so I can't see how 32 bit machines would add 64 bit numbers.