RISC-V, what do you think about ?

[HAL-42b]

Seems like the utter simplicity itself, I love it!

Definitely the best core for learning VHDL and processors.

[JoeN]

"32-bit, 64-bit, and 128-bit address space variants for applications, operating system kernels, and hardware implementations."

128 bit address space?  What is this good for?  64 bit is 16 EiB.  Are we pushing this for any computer system?  Tianhe-2 apparently has 1,375 TiB of memory or 1.375 PiB.  So the world's largest supercomputer is using less than 1/10,000th of the 64-bit address space so far.  I guess it might be useful sometime in the semi-near future.  When do you think the first computer with 16 EiB of memory will become sentient operational?

https://en.wikipedia.org/wiki/Tianhe-2

[HAL-42b]

"32-bit, 64-bit, and 128-bit address space variants for applications, operating system kernels, and hardware implementations."

128 bit address space?  What is this good for?  64 bit is 16 EiB.  Are we pushing this for any computer system?  Tianhe-2 apparently has 1,375 TiB of memory or 1.375 PiB.  So the world's largest supercomputer is using less than 1/10,000th of the 64-bit address space so far.  I guess it might be useful sometime in the semi-near future.  When do you think the first computer with 16 EiB of memory will become sentient operational?

https://en.wikipedia.org/wiki/Tianhe-2

Not much use if you think in terms of a normal Von Neumann machine. Extremely useful if your memory consists of many physically separate chunks which you may want to share or isolate according to some criteria.

Extremely useful for security in multi-processor systems.

For example if you want cores A B C D to be able to read from a chunk of memory but only cores D E to be able to write to it. Wide address space lets you manage this in a single instruction, moreover it lets you to verify its security in hardware, regardless of the code running.

In a sense it lets you program with your soldering iron, which I like, a lot. 

[C]

"32-bit, 64-bit, and 128-bit address space variants for applications, operating system kernels, and hardware implementations."

128 bit address space?  What is this good for?  64 bit is 16 EiB.  Are we pushing this for any computer system?  Tianhe-2 apparently has 1,375 TiB of memory or 1.375 PiB.  So the world's largest supercomputer is using less than 1/10,000th of the 64-bit address space so far.  I guess it might be useful sometime in the semi-near future.  When do you think the first computer with 16 EiB of memory will become sentient operational?

https://en.wikipedia.org/wiki/Tianhe-2

How about simple hardware reducing software load.
Storage directly mapped to memory space.
the simple memory management hardware would know if a write back was needed.

[JoeN]

How about simple hardware reducing software load.
Storage directly mapped to memory space.
the simple memory management hardware would know if a write back was needed.

128 lines just to put an address on the bus.
Commensurate decoding logic for every memory mapped device.
etc.

[ale500]

64 bit Processors today don't use 64 bit physical addresses anyways, they have like 42 or 48. It is an extensible ISA, they prepared it for growth, if tomorrow there is a new way of cpu in terms of quantum something of trinary systems or whatever, it may remain unused. But at the current rate, maybe in 10 years are 128 bit systems a real possibility

The RISC5 verilog shows a very compact and simple design of a 1 cycle CPU. Very nicely done . With the same concepts I designed a RISCV core, it mostly works

There is for instance a Cyclone IV board on ebay with external SDRAM for like 40 €, that is a nice target for the Oberon system, it needs a SDRAM controller but that is not that difficult... too many projects...

I tried the simulator and I find it just great. The kind of fun that where home computers some time ago, no windows, no drivers, no updates every other day...

[captbill]

ProjectOberon RISC5 core

I could try to add my TAP to this core, too.
and It will be interesting, as it comes with less complexity.

A TAP interface. I had to look that one up. "Test Anything Protocol" you mean? Sounds very interesting. So you have some 'TAP interface routines' you could apply to the RISC5, which sets up 'taps' for probing signals via JTAG? I have no clue how to go about 'tapping' the actual core but will gladly test anything like that on my setup. One question: does all this happen over USB or would you be physically probing some pin with a logic analyser?

[helius]

A TAP is a Test Access Port, for monitoring the internal memories of the CPU. It is needed for detailed testing and instrumentation of the CPU, for instance to capture or replay pipeline stalls, hazards, and exceptions. The interface from it to the debug host can be anything, but a serial protocol like SWD or JTAG would be a usual choice; USB would be absurd.
IEEE 1149.1 JTAG only has access to I/O pins; to implement real emulators and trace tools you must have a logic block with special access to internal data and control paths.

[legacy]

A TAP is a Test Access Port, for monitoring the internal memories of the CPU. It is needed for detailed testing and instrumentation of the CPU, for instance to capture or replay pipeline stalls, hazards, and exceptions. The interface from it to the debug host can be anything, but a serial protocol like SWD or JTAG would be a usual choice; USB would be absurd.
IEEE 1149.1 JTAG only has access to I/O pins; to implement real emulators and trace tools you must have a logic block with special access to internal data and control paths.

all of the above, but my TAP is not jtag driven, it implements a custom protocol which does not look like SWD
I am developing for hobby, tempted to put it on business, may be

[legacy]

There is for instance a Cyclone IV board on ebay with external SDRAM for like 40 €, that is a nice target for the Oberon system, it needs a SDRAM controller but that is not that difficult

while the Oberon mini FPGA board costs up to 150 USD 

[legacy]

so, they are both pronounced "risk-five", even if Risc-5 is Oberon, while Risc-V is Berkeley, and they are two different projects with little things in common

this Xcell article talks about Oberon System implemented on a low cost fpga, with a little review of the whole.

[captbill]

64 bit Processors today don't use 64 bit physical addresses anyways, they have like 42 or 48. It is an extensible ISA, they prepared it for growth, if tomorrow there is a new way of cpu in terms of quantum something of trinary systems or whatever, it may remain unused. But at the current rate, maybe in 10 years are 128 bit systems a real possibility

The RISC5 verilog shows a very compact and simple design of a 1 cycle CPU. Very nicely done . With the same concepts I designed a RISCV core, it mostly works

There is for instance a Cyclone IV board on ebay with external SDRAM for like 40 €, that is a nice target for the Oberon system, it needs a SDRAM controller but that is not that difficult... too many projects...

I tried the simulator and I find it just great. The kind of fun that where home computers some time ago, no windows, no drivers, no updates every other day...

How about this:
Just like the ProjectOberon emulator, there is a Macintosh Plus core + emulator up and running on the Pipistrello/Pepino.

You have to see this Mac+ emulator...awesome. In fact, I don't remember being able to load and run an 'emulator' of any sort without lot's of setup hassles, do you? These you just download and run like any other 'application'. I haven't yet flashed this to the Pipistrello, on the 'real hardware' mainly because the emulator is just so awesome.

http://saanlima.com/store/index.php?route=module/blog/view&blog_id=9

I literally have only played around with this core and managed to find and install ThinkPascal, which to this day has the neatest debug facility I have ever seen. I even found a full TCP stack written in ThinkPascal!...which I am very tempted to hook up to my new fangled ESP8266 'transparent UART' I just managed to get running with this thing.

This is probably a fun project for one of you Mac enthusiasts out there. I will be glad to assist where I can. Of coarse, to be fair and legal, the way to go about it is to find an old MacPlus on Ebay and build an awesome supercharged Mac+.

I think the <$200 price point is a great bargain when you consider all you are getting here. You want your FPGA development system to be oversized and not undersized. You can design small projects on oversized boards but you cannot build a big project if you have an undersized FPGA.

**BEEP ALERT lower your volume**
https://youtu.be/GM59aJmsZ4g

[C]

One thing I noticed on the very quick read of the risc-V

The section where they state it is a little endian machine and ethernet is big endian.

If you want to talk to something other then more risc-V you need to match.
If it does not match then you have to spend more instructions to make it match.

If you have a data structure then you are adding the convert to and convert from this data structure functions.
Extra programming that could be slow as it is not the normal way the CPU would access the data.

If you are building a computer that reads and writes most of it's IO via Ethernet would be a bad choice to pick a CPU where this took more time.

[edavid]

One thing I noticed on the very quick read of the risc-V

The section where they state it is a little endian machine and ethernet is big endian.

If you want to talk to something other then more risc-V you need to match.
If it does not match then you have to spend more instructions to make it match.

If you have a data structure then you are adding the convert to and convert from this data structure functions.
Extra programming that could be slow as it is not the normal way the CPU would access the data.

If you are building a computer that reads and writes most of it's IO via Ethernet would be a bad choice to pick a CPU where this took more time.

Yes, this is why we don't connect our X86 and ARM based computers to Ethernet 

[C]

One thing I noticed on the very quick read of the risc-V

The section where they state it is a little endian machine and ethernet is big endian.

If you want to talk to something other then more risc-V you need to match.
If it does not match then you have to spend more instructions to make it match.

If you have a data structure then you are adding the convert to and convert from this data structure functions.
Extra programming that could be slow as it is not the normal way the CPU would access the data.

If you are building a computer that reads and writes most of it's IO via Ethernet would be a bad choice to pick a CPU where this took more time.

Yes, this is why we don't connect our X86 and ARM based computers to Ethernet 

Just wanted to quote something and respond and skip the read the whole thing part.
Slower, more problems and more software does not prevent!
Just burns up a bunch of computer time.

[helius]

There are many different endian conventions used in I/O devices. When comparing CPU architectures, the main difference is the byte order between big-endian (e.g. Motorola) and little-endian (e.g. Intel) architectures. With I/O, it's the order of bits that matters, which is independent of the CPU's byte order. For example, serial links such as RS-232 are LSB first, and Ethernet is MSB first. The conversion takes place in the I/O hardware, takes no time at all, and is very rarely of concern to software.
A different issue yet again are interchange formats, that are defined so that data will have a consistent format regardless of the hardware used. Most Internet protocols are defined with big-endian numbers and macros like htons() are used to maintain this ordering. Some formats like ISO9660 CDROMs or DVDs consistently store two copies of numbers, one big-endian and the other little-endian. This is an issue for all computers and there is no way to avoid it by choosing the "right" byte order in hardware. If you have a byte-swap instruction it is very fast to do the conversion though.

[westfw]

The section where they state it is a little endian machine and ethernet is big endian.
If you are building a computer that reads and writes most of it's IO via Ethernet would be a bad choice to pick a CPU where this took more time.

Almost all of today's processors are little endian.   Most of them have some sort of byteswap instruction, so if you do things right, you end up adding a nanosecond or so to each 20+ns memory read or write.  Hardly deadly.  A near-SOTA intel processor with the Intel bi-endian compiler, with EVERYTHING in memory byteswapped, still out-performs a near-SOTA big-endian CPU.  Been there, did the tests, shipped the product...

[coppice]

One thing I noticed on the very quick read of the risc-V

The section where they state it is a little endian machine and ethernet is big endian.

If you want to talk to something other then more risc-V you need to match.
If it does not match then you have to spend more instructions to make it match.

If you have a data structure then you are adding the convert to and convert from this data structure functions.
Extra programming that could be slow as it is not the normal way the CPU would access the data.

If you are building a computer that reads and writes most of it's IO via Ethernet would be a bad choice to pick a CPU where this took more time.

Most machines are little endian these days, but swapping bytes around can be done quickly on most machines. Its often just a single instruction. What really hurts performance when building or dissecting message buffers is the inability to perform misaligned reads and writes. If you have to chop up words to pack them into a transmit buffer things get really slow. On machines which support misaligned reads and writes they are usually a bit slower than aligned ones. However, its much much faster than chopping things up and manipulating them in software.

[legacy]

On machines which support misaligned reads and writes they are usually a bit slower than aligned ones

MIPS can have misaligned-load/store instructions

why slower ? do you mean because it implies two sub-cycles, so the pipeline needs to be stalled twice ?

[helius]

Memory is always several times slower than instructions, so all software realignment does is increase code size. If you understand what you're doing you don't define unaligned data fields in the first place.
Misaligned load/store is difficult to implement correctly across cache-line and page boundaries. In the case of MIPS, several silicon errata were caused by this (mis)feature.

[coppice]

Memory is always several times slower than instructions, so all software realignment does is increase code size. If you understand what you're doing you don't define unaligned data fields in the first place.
Misaligned load/store is difficult to implement correctly across cache-line and page boundaries. In the case of MIPS, several silicon errata were caused by this (mis)feature.

When you are dealing with comms protocols you rarely get to choose whether things are aligned.

[C]

Memory is always several times slower than instructions, so all software realignment does is increase code size.

Suggests that inside processor should be risc to keep small CPU while in memory should be CSC to lower memory use.

[edavid]

Misaligned load/store is difficult to implement correctly across cache-line and page boundaries. In the case of MIPS, several silicon errata were caused by this (mis)feature.

That's odd, since MIPS doesn't have misaligned load/store (it uses LWL/LWR/SWL/SWR instead).

[legacy]

in MIPS, lwl/lwr and swl/swr are for accessing unaligned words in memory.
The actual specification is complicated, but what it boils down to is that

lwl RT, offset(RS)
lwr RT, (offset+3)(RS)

loads the 32-bit value starting at RS+offset, no matter what the alignment of that address is. swl/swr behave analogously.

RFE rotates the lower six bits of the status register by two to the right, so the "previous" interrupt/usermode state becomes the current state and the "old" state is copied into the "previous" state. This inverts what happens on an exception. RFE is normally found in the delay slot of a jump instruction of some kind.

[justanothercanuck]

i haven't seen a RISC (besides ARM) since PA-RISC...  that horse should have stayed dead.