The Moxie Blog - Latest Comments

Re: Notes on a novel in-game CPU: the dcpu-16

FT — Fri, 27 Apr 2012 09:52:23 -0000

Congratulations!http://www.youtube.com/watch?v...

Re: Notes on a novel in-game CPU: the dcpu-16

atgreen — Mon, 09 Apr 2012 20:37:50 -0000

[thanks for proof reading - edits made]

Even if the GNU compilers are never ported, binutils may be of value. Introducing a linker, with proper link-time relocations and optimizations (instruction shortening) would enable separate compilation in way that may be of value to developers. With a little bit of work, GDB can be made to do reverse debugging as well, which is pretty cool.

If ever a GCC port is produced, I think it would be fun to port the RTEMS RTOS. Not only is easy to port, but it can operate using cooperative multithreading, and is embedded in real space missions today.

And, FWIW, I've seen full GNU tools ports to targets with less memory!

Re: Notes on a novel in-game CPU: the dcpu-16

Muchmoxie — Mon, 09 Apr 2012 15:55:01 -0000

Not to be the grammar police or anything, but you've got some hyphen issues in your bit counts. Wherever "bit" is plural, there should be no hyphen. Example: the parenthetical toward the beginning of the second paragraph should be "16 to 48 bits long." Also, there's a typo: "comform zone."

With that out of the way, thank you for writing this insightful article. There are some significant issues with writing a C compiler for DCPU-16, so we (the community) may have to come up with a different, very C-like language and port GNU to it. And then there's the question of GNU's usability in a 128KB machine. Time will tell, I suppose.

Re: Using the Altera USB-Blaster on Fedora

Jad Younan — Sat, 31 Mar 2012 03:03:10 -0000

FYI, urJTAG worked perfectly for me. fedora 16, 64bit, altera usb blaster rev 3.

Re: Using the Altera USB-Blaster on Fedora

Kvapka Kvapla — Thu, 19 Jan 2012 14:25:51 -0000

Thank you very much, you saved the day!

Re: Branch delays

atgreen — Tue, 22 Nov 2011 16:38:31 -0000

True enough. And I've been thinking recently that a multithreaded core would be a better way to take advantage of idle logic anyways. I'm going to eliminate exposed delay slots for now.

Re: Branch delays

Albert — Tue, 22 Nov 2011 14:56:05 -0000

Delay slots are going to really hurt if anybody ever tries to implement the architecture with a fancier pipeline situation. When you have delay slots, you're letting an internal revision-specific detail leak out into the ABI, forever forcing you to emulate the behavior of the original core.

Re: GTKWave Tip #2: Translate Filter Files

tarun — Wed, 02 Nov 2011 01:16:46 -0000

atgreen I have one more question can you help me with this ...

I want different coloring for the wave form as shown in the figure
displayed in the following image taken from
http://gtkwave.sourceforge.net...

How can we have colors in similar way as shown in val[7:0]

Re: GTKWave Tip #2: Translate Filter Files

tarun — Tue, 01 Nov 2011 22:30:56 -0000

atgreen Thanks :).... That solved my problem .....

Re: GTKWave Tip #2: Translate Filter Files

atgreen — Thu, 27 Oct 2011 22:04:53 -0000

Hi. You just need a text file that has a mapping on every line, like this:

1F Hello
20 Goodbye

Then, once you've added your signal to the wave display in gtkwave, simply right click on the signal name and go to "Data Format" > "Translate Filter File" > "Enable and Select". Then click on "Add Filter to List", select the text file we created above, and you're pretty much done.

Re: GTKWave Tip #2: Translate Filter Files

Tarun_flashkicker — Thu, 27 Oct 2011 03:50:53 -0000

I'm a newbie and i want to diplay text for a give hexa number
for eg: 1F must mean Hello and must be displayed in gtkwave
Can i know how its done

Re: A simulation milestone for the Muskoka SoC!

r4 card 3ds — Sat, 15 Oct 2011 15:14:56 -0000

I have only one bus master (Moxie), and the slave device (bootrom) notice.Remember now that Moxie has both 16 - and 48-bit instructions.

Re: A simulation milestone for the Muskoka SoC!

atgreen — Sun, 02 Oct 2011 22:33:23 -0000

Thanks for the tips!

Re: A simulation milestone for the Muskoka SoC!

Bybell — Sat, 01 Oct 2011 16:55:34 -0000

As an FYI, something that makes debug a lot easier is if you start using the process filter feature in gtkwave. I used it for two things for the one set of instruction unit logic I wrote: (1) disassembly, and (2) color coding. Color coding is very handy for example for dispatch logic as you can say for example, all integer pipe ops are blue, all loads/stores are purple, etc. So if you zoom out real far--much farther than values being visible as hex/bin characters, you can simply look at splotches of color to determine if your dispatch logic is sending ops to the wrong pipe. The transaction filter is extremely powerful for decoding things like bus ops but takes a fair amount of work to develop however is very much worth it. Good luck on your project. -Tony Bybell (the gtkwave guy)

Re: Branch delays

atgreen — Fri, 30 Sep 2011 15:23:11 -0000

Hmm - both interesting ideas.

One thing I realized is that I don't actually need delay slots for jmp and jmpa, just the branch instructions. I should have had my coffee before making that post. The jmp instructions are really "call to subroutine" (I will be renaming them to call and calla soon). They do more than change the PC - they also push some data items onto the stack (return address, etc). So when the decode stage comes across a call/calla instructions, it will enter into a little state machine that sends push instructions down the pipeline. The fetch unit can go ahead and start filling the instruction fifo buffer right away, because the rest of the pipeline will appear to be stalled until the call instruction is finished. So it's all good.

Branches, on the other hand, will have delay slots.

I'm working on a bus arbiter right now to manage memory access requests for both instruction and data memory on the single bus. Then I'll add a RAM bus slave, implement load/store/push/pop, then finally the call/ret state machines.

Re: Branch delays

Nathan — Thu, 29 Sep 2011 10:10:19 -0000

You could enforce that instructions in delay slots must be X bytes in size. Or you could have separate jump instructions for short and long instructions in the delay slots.

Re: Qemu says Hello, World!

Ashish — Thu, 18 Aug 2011 11:02:12 -0000

Hi..I am facing similar problem but not able to figure out the issue..

qemu: fatal: Trying to execute code outside RAM or ROM at 0xfffffff0Segmentation fault

Could you point out something?

OS - OSX 10.6.8

Re: A Tiny Computer

qfqs720 — Wed, 20 Jul 2011 07:39:16 -0000

I need a Tiny Computer,it is useful for my work.

Re: On-chip communications

atgreen — Fri, 27 May 2011 00:15:33 -0000

The inspiration is there -- time is the problem... Let me see what I can do this week. It looks like GCC is broken. I'll start with that...

Re: On-chip communications

Curious — Wed, 04 May 2011 14:37:49 -0000

Given infinite time and energy/inspiration, where would moxie go?

Re: On-chip communications

Curious — Thu, 17 Mar 2011 16:03:11 -0000

ping?

Re: Pipeline hazards

S_bormann — Sun, 06 Mar 2011 13:46:08 -0000

Hi, when checking through your ISA and the simulator implementation. I came across that you are actually missing a means to load and store the condition code register, so there is a concurrency hazard.

If you have the following code (the branch would never be taken without interrupt):

cmp $r5, $r5
bne .Ljmp_somewhere_else

However, if an interrupt occurs directly after cmp executing:
cmp $r5, $r4 as last instruction with r4 = 4 and r5 = 5
the branch will actually be taken even though it would not be done without interrupt.

Re: Quartus II and the Cloud: Not There Yet…

Timhoppen — Tue, 01 Feb 2011 18:36:31 -0000

In the past, I have created a dummy interface and then set the MAC with ifconfig. Unfortunately, I don't recall if it fooled Quartus (I think it did)

Re: On-chip communications

atgreen — Wed, 22 Dec 2010 23:17:32 -0000

Moxie is on hold 'til Jan 1, as I have another urgent project to get out the door by then. Thanks for your patience!

Re: On-chip communications

Curious — Tue, 21 Dec 2010 17:09:13 -0000

Any updates?