Last visit was: Wed May 18, 2022 10:06 am
It is currently Wed May 18, 2022 10:06 am



 [ 138 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7, 8, 9, 10  Next
 FISA64 - 
Author Message
User avatar

Joined: Fri Jan 10, 2014 9:46 pm
Posts: 37
[removed due to user inquiry]


Mon Mar 30, 2015 2:56 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1678
Location: Canada
The branch displacement display bug was a software error.

Currently the system now hangs when interrupts are enabled. Interrupts were working beautifully at one point, but I've been modifying the kernel source. I'm pretty sure it's just a software problem of some sort.
The free task list is getting corrupted somehow making it impossible to start new tasks. The pointer to the free tasks is set to zero somehow. I tried setting up a data breakpoint at the pointer's address and the breakpoint is never taken (or it doesn't work). If the breakpoint is working correctly that means it's probably screwy hardware that zaps the free list pointer.
I think I've got semaphores working with the LWAR and SWCR instructions. However after reviewing how the instructions are used, I'm thinking it might be better to have the result from a SWCR stored in a general purpose register rather than a control register (CR0) as it is now. The issue here is changing the format of the SWCR instruction, which would then have to identify a target register. I think this could be accommodated because only register indirect mode is used ([Rn]) to identify the semaphore. The address of the semaphore is passed to a routine, so register indirect with displacement addressing isn't actually used. I note on the PowerPC that the store instruction uses only indexed addressing, so it doesn't bother with a displacement either.

_________________
Robert Finch http://www.finitron.ca


Tue Mar 31, 2015 2:55 pm WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1678
Location: Canada
I'm wondering about adding a bounds checking instruction to the machine after dealing with a number of bad pointers in the software. FMTK validates a task control block (TCB) pointer in a number of locations. This is basically a bounds check and check that the pointer is modulo 1024 (the size of a TCB).
Code:
ValidateTCBPtr:
    push    r2
    and     r2,r1,#$3FF
    beq     r2,.0001
.badPtr:
    ldi     r1,#0
    pop     r2
    rtl
.0001:
    cmp     r2,r1,#TCB_Array
    blt     r2,.badPtr
    cmp     r2,r1,#TCB_ArrayEnd
    bge     r2,.badPtr
    pop     r2
    rtl

This entire routine (and others) could be replaced by a bounds check instruction that executes in a single cycle. And pointer validation is a fairly common software function. It would take a set of registers in the processor (assuming more than one bounds check is desirable at a time). A set of upper bound, lower bound, and modulo mask registers might help with pointer validation. Of course, it would turn the processor into more of a CISC machine but the machine is already running at a low clock frequency due to other system constraints.

_________________
Robert Finch http://www.finitron.ca


Thu Apr 02, 2015 6:56 am WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1690
Could this be handled instead as an MMU function? Define some set of address ranges, each of which has bounds and alignment constraints.


Thu Apr 02, 2015 9:13 am

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1678
Location: Canada
Quote:
Could this be handled instead as an MMU function? Define some set of address ranges, each of which has bounds and alignment constraints.

I was thinking of something along the lines of the x86 BOUND or 68000 CHK instructions. I suppose there could be a set of registers to define address ranges in the MMU. it is bounds mainly against address ranges. It might be useful to have the pointer type match against a particular address range. For example pointer type one fits in address range one, pointer type two in address range two, etc. It would require tag bits to indicate a pointer type though.

A test setup with 64 - 192 bit (64,64,64) bounds registers increased the size of the core by about 2%. 32 bounds registers are available in user mode, all 64 can be used in kernel mode. I added a modulo mask check in addition to upper and lower bounds. Many times operating system structures (or other structures) are made some multiple of two in size. So the least significant bits of a pointer can be checked for zero. Also rather than use general purpose registers, special purpose bounds registers are present. As they essentially hold static values while a program runs. Now I'm wondering if it's possible to double up on the usage of the bounds registers, for example to hold program constants.

_________________
Robert Finch http://www.finitron.ca


Thu Apr 02, 2015 10:29 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1678
Location: Canada
Well I got the bounds registers and CHK instruction working. I'll turn the processor into a CISC machine yet. I've been working mostly on software lately. I'm trying to get the debugger going well enough that I can use it to find a problem in FMTK. The debugger is implemented with some GDB style commands. Code size for the boot rom has gone past the 48kB mark.

_________________
Robert Finch http://www.finitron.ca


Sat Apr 04, 2015 6:23 am WWW
User avatar

Joined: Fri Jan 10, 2014 9:46 pm
Posts: 37
[removed due to user inquiry]


Sat Apr 04, 2015 11:54 am

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1678
Location: Canada
She's breathing but it doesn't work very well. It crashes and hangs all the time. I can set a breakpoint manually with code using the processor breakpoint registers, and the debugger will become active when the breakpoint is hit. It dumps a listing of machine code with the line of the breakpoint hi-lited. The neat thing is single stepping mode can then be turned on but it doesn't work correctly yet. (It re-excutes the same line that caused the break instead of moving to the next line).
The debugger supports some GDB like commands: 'q' to quit, 'x' to examine memory, 's' to single step and 'n' to next step. It's not going to be a GDB clone though. Currently there are breakpoint registers which can be set (in theory) but it hangs at the moment when a register is set. The debugger is centred around the processor's debug registers. For instance typing 'i0=123456' will set an instruction breakpoint at 123456 using breakpoint register #0. 'd' sets a data breakpoint, and 'ds' sets a data store only breakpoint. All of the IO is console based at the moment, featuring full screen editing. It's a work in progress.

_________________
Robert Finch http://www.finitron.ca


Sun Apr 05, 2015 6:18 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1678
Location: Canada
I took a step backwards and configured the system to be only single core while I develop some software. It's faster to build the system that way. The bootrom has now been mostly re-written in 'C', as the 'C' compiler seems to work okay. I managed to successfully compile several of the MINIX sources, whether or not the compiler generated correct code is another thing.

_________________
Robert Finch http://www.finitron.ca


Tue Apr 07, 2015 9:19 pm WWW

Joined: Tue Jan 15, 2013 10:11 am
Posts: 114
Location: Norway/Japan
As you are developing hardware and software at the same time, would it make sense to write a CPU emulator (to run on a PC) and test the software there? The presumption would be that the emulator would be "right" and when the software works one could be fairly certain it's the hardware, and not the software if it doesn't work on the real thing.. I guess you have maybe already considered such an approach though.

-Tor


Wed Apr 08, 2015 5:18 pm

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1678
Location: Canada
Quote:
would it make sense to write a CPU emulator (to run on a PC)

I've found that I can run software in the logic simulator to find bugs at least in the startup code before the simulator runs take too long. I probably should at some point write an emulator. I've written an emulator before so I may be able to reuse some of the code. A nice GUI to go with it would be nice.

I figure this project's probably about 30,000 lines of code (or more?) including things like the compiler and peripherals. The bootrom listing itself is 16,000 lines long. Of course the project's built on prior work.

_________________
Robert Finch http://www.finitron.ca


Thu Apr 09, 2015 9:11 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1678
Location: Canada
I have put an initial archive of the FISA64 emulator in my GitHub area. It is being written using Visual C++ Express. The emulator mostly doesn't work. but it's possible to load a text file containing a program image, and step through it. At this point only a handful of instructions are properly executed.

Running FISA64 the FPGA version hangs when the screen scrolls in the debugger, but not when the screen scrolls outside of the debugger. This has me confused as there is only one screen scroll routine. The task list of FMTK also gets corrupted somehow. It insists there is a task running on CPU #45. I get the same results regardless of enabling or disabling the cache and branch prediction. I suspect these problems are a combination of hardware and software issues :( Unfortunately I can't get the debugger working well enough to be useful.

_________________
Robert Finch http://www.finitron.ca


Sat Apr 11, 2015 5:39 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1678
Location: Canada
Screenshot of the emulator:
Attachment:
FISA644.gif


You do not have the required permissions to view the files attached to this post.

_________________
Robert Finch http://www.finitron.ca


Sat Apr 11, 2015 5:44 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1678
Location: Canada
Major league bug fix pending, found by running code In the emulator. Compiler generated names weren't being mangled enough in some cases. The result is that the compiler generated name would conflict with an assembler pseudo-op and the assembler would interpret it as a zero value. So if a var was called 'fill' in the 'C' source code it would feed through to the assembler as a label 'fill' which conflicts with the assembler's 'fill' directive. The solution was to make sure all compiler names are mangled by adding an '_' to the end of the name. Now to go back, rebuild the system and see if everything works okay.

_________________
Robert Finch http://www.finitron.ca


Sun Apr 12, 2015 12:57 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1678
Location: Canada
The emulator worked well enough to replicate the bug with the screen scroll in the debugger. I was able to find and fix the bug. It had to do with the video bios trying to call itself while not being re-entrant. With the screen scroll fixed I was able to step through a test program, but the single step sometimes steps by two or three instructions instead of just one.
Next to get interrupts working with the multi-tasker.

I had to come up with a virtual keyboard for the emulator. I just used a bunch of buttons on a form. I wish there were a way to hack into an existing virtual keyboard and interface it to the emulator.

_________________
Robert Finch http://www.finitron.ca


Mon Apr 13, 2015 11:09 am WWW
 [ 138 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7, 8, 9, 10  Next

Who is online

Users browsing this forum: CCBot and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software