191–200 of 225 posts
Earlier quoted context omitted.
Check your router's CPU. I own 4 routers and all of them use MIPS. RISC-V is more like Graphene, it's yet to leave the lab.
Tell it to Digikey: https://www.digikey.com/en/products/detail/seeed-technology-... (I've got a single board computer from those people that I got in, I think, 2019)
In 2010 MIPS wanted $2 million from Berkeley to allow them to use the MIPS instruction encodings for processor cores that Berkeley would design entirely themselves. So they made up their own encodings instead. The rest is history. In many ways modern MIPS and RISC-V are pretty much just different binary encodings of the same ideas. [this was already posted as a comment in a thread, but on reflection it probably deser…
This is more or less analogous to Blackberry moving to Android, isn’t it? Storied, old-guard tech company loses most of its market share, trades in its first-party stack for a rising open-source alternative. Is MIPS still a big enough name to make this much of a coup for RISC-V? Or is this the last-ditch effort of a fallen star of the semi market?
Check your router's CPU. I own 4 routers and all of them use MIPS. RISC-V is more like Graphene, it's yet to leave the lab.
Earlier quoted context omitted.
> I realize I've sort of just re-invented Javascript. You've re-invented UCSD P-code. https://en.wikipedia.org/wiki/P-code_machine
BCPL ocode is quite a bit older the UCSD P-code. The BCPL compiler always outputs ocode. Then a back end for the particular system statically generates machine code (or assembly language) Back in 1983 I helped take a BCPL running on a VAX and add a M6809 back end to it.
But for those who design SoC, and who needed embedded CPU of intermediate power, it's very good news. ARM is expensive here (it's considered cheap compared to Intel, the embedded world is different). The RISC V newcomers are interesting but... new, and it always get a bit of time to bring solutions to maturity, which matters in embedded. And if ARM owns the high-end (where a design must be co-optimized for the latest advanced nodes to really shine, which is very labor intensive and costly), for the mid-range it's much more open.
MIPS had a good mid-range design with the I-7200. Their problem was that the old MIPS ISA was not dense enough (larger I cache, larger Flash footprint) compared to the competition, and their compact versions not good enough. So they designed for the I-7200 a new ISA, nanoMIPS, which has "MIPS" in its name but is completely different. And guess what: nobody cared. It became another proprietary ISA, only supported by MIPS own GCC version.
But still, the design was good, and in particular the LLC/coherency support is much more mature than what many newcomers offer today. Which shouldn't be a surprise, as it's the result of a long line of (good) mid-range CPUs.
By evolving their design to RISC-V, MIPS will have one of (if not the) best mid-range CPU/cluster IP in the market soon for quality vs price --- depending on how fast the competition move, they're definitely not sitting still! And RISC V will solve the toolchain/tools support nanoMIPS has. If there had been such a RISC I-7200 equivalent a few year ago, I may have used it.
So very nice, and I look forward for more competition in the embedded mid-range CPU IP market soon.
Earlier quoted context omitted.
> it's yet to leave the lab. You can buy them on Amazon. https://www.amazon.com/dp/B08W2J9B8J https://www.mouser.com/ProductDetail/?qs=pUKx8fyJudB1sOWbbEn...
> You can buy them on Amazon. > Currently unavailable. We don't know when or if this item will be back in stock. Clearly not!
Earlier quoted context omitted.
SPARC is well known to be different enough (big endian, register windowing of the stack, alignment, etc.) that it exposes a lot of bugs in code that would be missed in a little-endian, x86 derived monoculture. https://marc.info/?l=openbsd-bugs&m=152356589400654&w=2
I always found SPARC's stack handling to be very elegant and I write enough of low level code that these architectural details do from time to time impact me, but isn't it largely irrelevant for the industry at large? After all MIPS's original insight was that machine code was now overwhelmingly written by compilers and not handwritten assembly, so they made an ISA for compilers. I think history proved them absolutel…
These days "bare metal programming" means writing raw HTML yourself in a text editor, no CSS, no JS.
Earlier quoted context omitted.
BCPL ocode is quite a bit older the UCSD P-code. The BCPL compiler always outputs ocode. Then a back end for the particular system statically generates machine code (or assembly language) Back in 1983 I helped take a BCPL running on a VAX and add a M6809 back end to it.
Ah yes, it even rates a mention on that Wikipedia page. Thank you for pointing this out. 1966! Funny how all these supposedly 'new' concepts really go back all the way to the beginning.
This is more or less analogous to Blackberry moving to Android, isn’t it? Storied, old-guard tech company loses most of its market share, trades in its first-party stack for a rising open-source alternative. Is MIPS still a big enough name to make this much of a coup for RISC-V? Or is this the last-ditch effort of a fallen star of the semi market?
Check your router's CPU. I own 4 routers and all of them use MIPS. RISC-V is more like Graphene, it's yet to leave the lab.
Earlier quoted context omitted.
Isn't that basically what Android Runtime does?
I don't know much about Android specifically. Is it still heavily Java-based? There are a lot of universal-binary candidates both current and historical. Javascript, Java, SPirV, LLVM intermediate representation are some of the current ones. So, this isn't a new idea, it's just that most of the software I use regularly is compiled specifically for x86-64. Maybe it would be better if that were a rare exception rather…
NDK's main purpose, from Android team point of view, is for writing native libraries.