This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).
|
wrote: > > I noticed the other day that it's been over a year since > I first posted a description of the YARD-1 processor. In > the event that anyone is wondering about its' status, I'm > currently working on finishing an instruction set testbench, > to be followed by a long-delayed code cleanup, at which > point I'll put together another snapshot with the tools and > code. ( This being a 'spare time' project, I won't predict > exactly when that will happen.) Just looking back a the old posts quickly it looks like you don't have a overflow bit. How do you handle overflow on signed compares? Ben Franchuk. -- Standard Disclaimer : 97% speculation 2% bad grammar 1% facts. "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk |
|
|
|
I noticed the other day that it's been over a year since I first posted a description of the YARD-1 processor. In the event that anyone is wondering about its' status, I'm currently working on finishing an instruction set testbench, to be followed by a long-delayed code cleanup, at which point I'll put together another snapshot with the tools and code. ( This being a 'spare time' project, I won't predict exactly when that will happen.) A brief description of the instruction set testbench: 1) Each verification test is driven by an assembly source file that includes verification directives: <bitsy1.lst> ; try out ff1 with single bit set 00000002 05f0 mov r0,#$8000_0000 00000004 7401 ff1 r1,r0 .verify r1,#0 00000006 6010 lsr r0 00000008 7401 ff1 r1,r0 .verify r1,#1 Currently, the .verify directives are limited to one per address, and are restricted to test conditions of the form "register,#constant". Upon assembly of the above, the assembler coughs up a 'verify' file including the source line/address/register/value info: <bitsy1.vfy> [bitsy1\bitsy1.asm:18] 00000004 r1 00000000 [bitsy1\bitsy1.asm:22] 00000008 r1 00000001 2) The processor VHDL testbench code dumps a record of activity to an ASCII log file: <sim.out> --------------------------------------------------------------------- --- 135 ns: EVB tp=6008 RST=1 IRQ=1 dip_sw=00 led_bar=111 L7=00 R7=00 135 ns: DBUS d_addr=80000000 d_dat=00000000 d_cs*=1 d_rd*=1 d_wr*=1 d_wen*=0011 135 ns: IBUS i_addr=008 i_dat=6010 i_cs*=0 i_rd*=0 i_wr*=1 135 ns: RF Writeback R1=00000000 135 ns: ALU ain=00000000 bin =00000001 wb_bus=00000000 sr =00000000 cg_ext=00000000 cg_pow=00000001 cg_min=00000001 cg_out=00000001 135 ns: EX pc_reg_p1=004 ireg=7401 ex_null=0 140 ns: Register File 80000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 --------------------------------------------------------------------- --- 3) A perl script reads the verify file, builds an associative array of test addresses, then wades through the simulator output file looking for matches: YARD-1 Verify Version 0.00 Passed test @ 00000004 [bitsy1\bitsy1.asm:18] Passed test @ 00000008 [bitsy1\bitsy1.asm:22] <...> Failed test @ 00000100 [bitsy1\bitsy1.asm:273] Expecting r1 = 00000020, was 0000001f Total Errors = 1 4) Each of the individual tests lives in its' own subdirectory, with a top level batch file to run any given test (haven't gotten around to writing a makefile yet). e.g., typing "v bitsy1" does the following: - assembles the file bitsy1\bitsy1.asm - copies the VHDL-ified object file to the VHDL source directory - compiles and runs the simulation - copies the simulator output file into the bitsy1 subdirectory - runs the <verify.pl> perl script to see if the output file matches the verify file This should be fairly easy to automate completely, allowing one to run some or all of the tests unattended while logging the results. Brian old YARD-1 posts: assembler, debugger info: http://groups.yahoo.com/group/fpga-cpu/message/332 processor description ( a bit outdated ): http://groups.yahoo.com/group/fpga-cpu/message/106 |
|
|
|
--- In fpga-cpu@y..., Ben Franchuk <bfranchuk@j...> wrote: > > Just looking back a the old posts quickly it looks like > you don't have a overflow bit. How do you handle overflow > on signed compares? Ben Franchuk. > Short answer: I dropped the short conditional branches from the instruction set, leaving room for more skip conditions; this allows for a full set of signed/unsigned register >=< register conditions. This means that register-register compares no longer need to be done using a (possibly overflowing) subtract. Currently implemented skip conditions: .bs bit set .bc bit clear .z zero .nz non-zero .pl plus ( skip.bc Rn,#31 ) .mi minus ( skip.bs Rn,#31 ) .plnz plus-and-non-zero .miz minus-or-zero .eq ra == rb .ne ra != rb .a always ( skip.eq r0,r0 ) .n never ( skip.ne r0,r0 ) New reg/reg skip conditions (not implemented yet): unsigned: .hi higher .hs higher or same .ls lower or same .lo lower signed: .gt greater than .ge greater than or equal .le less than or equal .lt less than Long answer: From my orignal writeup: > There's no compare instruction; without flags or 3-operand > register files, there's no place to store the result (without > clobbering the source register). > <snip> > > - add/sub use "skip on no carry/borrow" instead of "carry in" > variants > > - implementation: when instruction bit 11 of ADD/SUB is set, > the next instruction is skipped if NO carry/borrow occured; > this allows you to stick a "fixup" instruction in the skip slot > > - any other overflow/underflow HW checking would be via exception > mechanism The existing "skip on no carry/borrow" let you handle extended precision arithmetic without a carry flag, but don't help catch signed overflow. Without a compare instruction to set either condition codes or a result register, it's a bit hard to detect an overflow without using some sort of trap mechanism. Unfortunately, there aren't enough opcode bits to implement trapping/non-trapping versions of add and subtract; I'd considered adding a control register bit to enable/disable arithmetic traps for all add/sub instructions, but that seems too extreme. If I do implement arithmetic traps, it would probably be as an instruction prefix that enables traps only for the following instruction. Brian |