Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #6460

Re: New 16 bit CPU by Notch

Show all headers | View raw

In article 
<16793541.381.1333641651447.JavaMail.geo-discussion-forums@ynib40>,
 MitchAlsup <MitchAlsup@aol.com> wrote:

> Can you explain the difference between next-word (0x1F) and litteral (0x20-0x3F)

Literal has no extra word, use 5 of the 6 bits in the field as a constant.

> But in general, it looks like you did a nice job. But I think you could get more 
> major op codes if you used a 5-bit a and b fields. This would give you access to 
> all the 'cool' operand types (less the 0x20-0x3F range).

I agree that the opcode list is skimpy, I think this will cause code bloat, 
but I do not know how much. (Also I am not Notch.)

> Having the PC as a readable and writable operand is BAD NEWS for big OoO. 
> Some constraints, here, might help without eliminating this cool PDP-11-like feature.

Most of the RISC chips have PC relative, so loading a (fake) PC that works is not a problem.
If PC is a destination you are doing a computed branch, ahh, now I see the issue.
You want most branches to be to a constant address/offset, so the branch predictor
can fetch the instructions early, instead of stalling until the branch address is computed.
With every fourth instruction on average being a branch, this is death for performance,
even more so when you count the ~5 to ~30 pipe stages.

The seemingly brain damaged code that gets generated for short case statements now make sense.
It would be nice if I could hint the CPU early on a computed branch to get around this.
A load LINK with intent to branch, followed later by branch to link. (PowerPC?)

> I suspect that lack of major opcode space is more limiting than lack of 
> 8-bit support (I could be wrong). But you don't have room to load a halfword 
> and then split it into 2 characters--nor room to add it. So, this might come 
> back to haunt you.

Yes, I have toyed with similar over simplifications, only to get scared I missed 
something big, besides the obvious performance loss in all the non-common cases...
I consider the lack of "IFGE a>=b" to be a flaw.

> I further suspect that lack of signed (versus unsigned) will be limiting, 
> certainly by the time you expand to 32-bits it will be.

I kind of like the way he sidestepped the issue of sign.
I do not think it sane to expand this arch to 32 bits, crazier has been done, x86.
The epic blunder with PC branching means this CPU will not get built, 
besides into a game as a software toy controller.

As a software only system this should have a nice fast interpreter/compiler.
Which is a whole other ball of wax.
I like it better than handing the user Basic or Java.
Being 10 to 100 times faster than Java will enable some crazy new features. (Swarm bots?)

Teaching an artist to program in Java is futile, so give those that can program "real" 
(sandboxed) tools. Toy languages like Java have little place outside the classroom.

Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

New 16 bit CPU by Notch Brett Davis <ggtgp@yahoo.com> - 2012-04-04 13:36 -0500
  Re: New 16 bit CPU by Notch MitchAlsup <MitchAlsup@aol.com> - 2012-04-05 09:00 -0700
    Re: New 16 bit CPU by Notch Brett Davis <ggtgp@yahoo.com> - 2012-04-07 02:09 -0500
  Re: New 16 bit CPU by Notch EricP <ThatWouldBeTelling@thevillage.com> - 2012-04-05 13:39 -0400
  Re: New 16 bit CPU by Notch gavin@allegro.com (Gavin Scott) - 2012-04-25 13:49 -0500
    Re: New 16 bit CPU by Notch, version 1.5 Brett Davis <ggtgp@yahoo.com> - 2012-04-27 00:12 -0500
  Re: New 16 bit CPU by Notch Walter Banks <walter@bytecraft.com> - 2012-05-28 18:10 -0400

csiph-web