OSDev.org

Combuster wrote:Even better: Hitachi SH-4 with Windows CE (dreamcast, anyone?).

Didn't the Dreamcast WinCE have only the core Windows stuff and DirectX, no GUI?

Troy Martin wrote:I've started writing an open-source 16-bit processor in C that could very easily be made 32-bit or higher. I'm planning on releasing it as soon as I finish the CSR system (Call Service Routine) and a simple assembler.

A processor? In C? Do you mean a VM, too? Or are you writing a processor simulator?

steveklabnik wrote:

Troy Martin wrote:I've started writing an open-source 16-bit processor in C that could very easily be made 32-bit or higher. I'm planning on releasing it as soon as I finish the CSR system (Call Service Routine) and a simple assembler.

A processor? In C? Do you mean a VM, too? Or are you writing a processor simulator?

AT&T's Hobbit is how I interpreted it on the first pass.

Interesting... a C machine... I guess this makes sense. I'd heard about the good 'ol Lisp machines, I guess there's no reason why there couldn't be a C one...

PowerPC rocks! Where else can you find instructions like stfsux and eieio?

Colonel Kernel wrote:PowerPC rocks! Where else can you find instructions like stfsux and eieio?

ROFL

[/quote]I just wish intel or amd would start making RISC desktops(processors that is).[/quote]

x86 is pretty much RISC once you get past the microcode stage. That's why their pipeline is so long.

And yes, enforce in-order execution of i/o is my favourite instruction. Blatantly designed around the acronym, similar to the Continuous Unnecessary Notification Test that was invented at my place of work last year. (No, that is not made up.).

Actually what I meant was I'm writing a processor emulator in C for a processor I designed.

Troy Martin wrote:Actually what I meant was I'm writing a processor emulator in C for a processor I designed.

Did you design a processor (you'd probably have done this in an HDL), or an ISA (you've come up with opcodes and planned out how the opcodes and the necessary operands will be encoded into appropriately-sized words, etc)?

Colonel Kernel wrote:eieio

Until I looked up what EIEIO did (Enforce In-Order Execution of I/O) I thought it might have started playing Old MacDonald Had A Farm EIEIO!

madeofstaples wrote:

Troy Martin wrote:Actually what I meant was I'm writing a processor emulator in C for a processor I designed.

Did you design a processor (you'd probably have done this in an HDL), or an ISA (you've come up with opcodes and planned out how the opcodes and the necessary operands will be encoded into appropriately-sized words, etc)?

ISA.

I'm still waiting for asynchronous CPUs to become popular... the days where things aren't measured in dumb clock cycles and just cause div takes a long clock cycle to complete, doesn't mean a nop should have the same long clock cycle. (plus power saving would be awesome)

Don't Intels (and probably AMDs) processors already do this? I remember reading somewhere that add is 3 clocks and div is 7 clocks or something like that.

Perhaps I have also misunderstood you, earlz. If a nop and a div take the same amount of time, wouldn't that be a single-cycle machine? The x86 has been pipelined for years now (one of the reasons why the underlying design is a RISC), so it shouldn't suffer from that. Forgoing branch prediction and other worst-case situations, the throughput should be much better than any 1 single instruction's time.

actually, even on the 8088, different instructions took different numbers of cycles

current CPUs not only use multiple cycles per instruction, but also allow instructions to take less than a cycle (for example, on northwood and later, each ALU can perform add and subtract instructions in half a cycle, meaning each one can perform 2 per cycle, with northwood, one of them could do the same with multiplication (but the others take longer) but beginning with prescott all ALUs can perform multiplication in a single half-cycle

several years ago, the number of cycles an instruction takes got to be so well hidden behind unpredictable timing issues, that intel declared it to be completely useless information, and stopped printing charts with this information