input/output instructions

[agner]

I prefer to have separate instructions for input and output, and a separate address space for in/out instead of memory mapped in/out. The reasons are:

• All memory addresses are relative and position-independent, while input/output addresses are usually absolute addresses. Code and data memory has a 64-bit address space, while we need much less than 264 input/output addresses. It is useful to have separate address spaces for in/out and memory.
• I prefer to keep the memory map on-chip for faster access. Memory mapped in/out would increase the size of this map.
• The security features of Forwardcom includes detailed control of access rights for device drivers. Most or all current systems have unlimited access rights for device drivers. It would be nice to be able to control access rights at the level of individual input and output ports. It may be useful to have this extra security in a future system.

I have a question regarding the serial input/output. My FPGA board has a RS232 interface, tunneled through a USB cable. I can make an 8-bit input port and output port for serial input/output through this. But I also need extra functions for checking things like buffer empty, buffer overflow, transmission failure, flush buffers, etc. Before I assign arbitrary port addresses and bit patterns to these purposes, I want to know if there is any existing standard I can use for this? The system must be able to support binary data for loading a program, as well as character streams for STDIN/STDOUT when a program is running.

[Dom324]

"Code and data memory has a 64-bit address space, while we need much less than 264 input/output addresses."

I'm not so sure. AMD just announced their Smart Access Memory technology, which essentially gives the CPU direct access to the GPU memory (this improves performance in various applications by few %). Considering that current GPUs have 8-48GB of VRAM, we would need more than 32 bits to map the whole GPU memory.

The amount of VRAM will only grow + in servers you can have several GPUs, so mapping the memory of all of them will require even more address bits.
In the future there will be even more accelerators connected to the CPU (AI, FPGAs...) so having 64 bits of IO address space isn't that bad idea.

The other option is to map the GPU VRAM into the CPUs 64bit memory address space, but to me it looks like you're not a fan of that...

[HubertLamontagne]

I imagine if it ever comes to that, with large 3d graphics adapters, by that point you'd probably memory-map the device space and use something like paging and chained DMA and bus mastering and even an IO-MMU (which is now a thing on modern PCs). The culmination of this trend is that on the PS4, where the CPU and GPU share the same RAM (and it's designed this way on purpose).

It's true that on PC, there's a whole bunch of special memory range setups to bypass caching and allow or disallow all sorts of things like reordering, write combining, etc... and you'd want to avoid that.

[agner]

Hubert Lamontagne, I am not sure you would want to have a a large graphics coprocessor. I would prefer to have a multicore ForwardCom processor with large vectors rather than a smaller ForwardCom processor connected to a graphics coprocessor using a different instruction set.

[HubertLamontagne]

If you can do efficient bilinear texturing on a general purpose CPU, that would already be better than Intel (who had to add a texturing unit to the Larrabbee) and Sony (who had to add a GPU to the PS3 when they realized that they couldn't efficiently texture polygons on the Cell). And it would probably be a mini revolution in design. Personally, I've come to the conclusion that dedicated GPUs will probably always be with us due to the texturing problem (to my chagrin as I'm big into looking into voxel rendering, alternatives to polygons, and software rendering in general). You're smarter than me, maybe you can figure this out. :3

[Kulasko]

You could provide some fixed-function-hardware to some cores, accessed as an extension of the standard ForwardCom ISA. ForwardCom already has decode space reserved for extensions, there are also plans for adding an FPGA portion to each core.
But in general, the viability and efficiency of a "ForwardCom GPU" is not yet researched.

[Cuminies]

multiple versions of forwardcom cpu that have compatible base instruction sets and different extended instruction sets to satisfy hubert an agner both?

[HubertLamontagne]

multiple versions of forwardcom cpu that have compatible base instruction sets and different extended instruction sets to satisfy hubert an agner both?

Forwardcom is 100% agner's baby, I wouldn't dare attempting to fork it :P

[agner]

Not 100%. Hubert has fertilized it with valuable insight in hardware design :-)