Last visit was: Sun Aug 01, 2021 3:41 am
It is currently Sun Aug 01, 2021 3:41 am



 [ 24 posts ]  Go to page Previous  1, 2
 FT68000 - 68k similar core 
Author Message

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
I haven't done much more on this project. Instead I've taken up writing a sci-fi story which is taking up more of my time.


I had a brief look at floating point support. I've written some FP primitives but they have limited pipelining so they use a slow clock. I really should go back and add more pipelining to increase the fmax.


I'm backtracking on the mailbox implementation. It's questionable to connect every mailbox to every sender in parallel. I think it would be slow because of all the routing. So it's back to having a message queue in the router component.

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


Tue Jun 26, 2018 5:18 am WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1627
> SF story
Interesting - hope we get a chance to read it one day. Does it involve a rogue CPU?


Tue Jun 26, 2018 8:22 am

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
Quote:
Interesting - hope we get a chance to read it one day. Does it involve a rogue CPU?

The story involves an immortal woman escaping from a planet about to be fried by the star. Sorry, no rogue CPU in the story. There is only limited AI in the story. Takes place in about a 1990 technical level, with one or two exceptions.

I’ve written about 11,000 words over the last two weeks. It’ll likely be a year or so before the story is done.

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


Wed Jun 27, 2018 1:15 am WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1627
It's a huge amount of work, I know that - but not from personal experience. Good luck with the endeavour!


Wed Jun 27, 2018 7:12 am

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
Added states to support floating point to FT68000x16.v. While the 68000 supports several different operand types (single, double, long, word, byte, etc). The FT68k will only support doubles (64 bits) to begin with. There is some finagling of the datapath necessary as the FT68k previously didn’t support data over 32 bits.

Used an unused mode, reg combination of the 68k (mode 7, reg 6) to implement reading of 64-bit immediate constants. Immediate constants are handled slightly different in FT68k. Rather than look at the op size, there is a separate mode, reg combination to support encoding 16, 32, or 64-bit constants. This allows longer operations to make use of shorter constant encodings. It does make the required instruction encodings not 100% binary compatible, but very close. Since FT68k is little endian constants are encoded differently than the 68k anyway.

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


Fri Jun 29, 2018 4:11 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
Now that I selected multiple mode,reg combinations to represent immediates, I've decided that was a bad way to do things and to change it all around and use just a single mode,reg combo. This came from a desire to support extended precision (96 bit) arithmetic. Instead the immediate values are going to be processed with bit 15 of a 16 bit parcel indicating to include more bits in the constant (0 means include the next parcel). The problem is that so many different sizes of constants are required. I want to be able to support at least 128 bits and lower. 128 bits take 9x 15 bits. A small constant (less than 16 bits) will have bit 15 set to indicate that is the last parcel required. I'm going to modify the core so that addresses and displacements work the same way.

I came up with an extended precision (96 bit format) for the FPGA makeing use of 18x18 multipliers.

Attachment:
DXPres.png


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

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


Sat Jul 07, 2018 6:01 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
Got back to this project thinking I may reuse it in a new project.

Modified FT68000 and created a new version without the task support. The original FT68000 supported multiple task registers in hardware. This made task switching fairly painless for up to 512 tasks. The processor also automatically switched to exception processing tasks instead of vectoring to exception processing routines. The new version dropped all this support and works more like the original 68000. One key difference is the lack of two different operating modes. The new FT68000 version has only a single mode, single stack pointer. Multiple levels of operating modes are going to be supported by using a multi-core processor. Each core will have a distinct operating level.
For the target FPGA device, at least a quad-core will be developed. One core for supervisor mode, handling external exceptions, and three cores for processing user tasks which operate in an external exception less environment. On the user cores task switching will be triggered through OS calls.
Added to the core are two prefix instructions (RSV:, CRSV:) that cause the next load or store operation to reserve the load/store address or clear a reservation on the store address. If the reservation clear prefix is used the store will not complete unless the address is reserved. The status of the store operation is returned in the carry bit of the status register. The address reservation mechanism is a powerful mechanism inherited from RISC designs. Highly useful to create semaphores and other objects required for multi-core operation.

Core size is about 6748 LUTs or 10,800 LC’s.

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


Mon Aug 24, 2020 4:23 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
Setup multiple register sets / contexts. The data register file which contains eight registers is no more compact than a data register file that contains 64 registers. So, the core goes with a 64-entry data register and 64-entry address register files, of which only 8 register may be selected at any one time. Each group of eight registers is referred to as a register context. Which register context is active is determined by the AXC register. The AXC standing for Active Execution Context, is a three-bit register reflected as the upper nybble of the program counter. Placing the AXC in the program counter allows it to be saved and restored during exception processing. This would reduce the possible size of a program from 4GB down to 256MB. However, also added to the core is a code segment register. The addition of a code segment register makes losing the upper bits of the program counter relatively insignificant. Code modules are seldom more than a few megabytes in size. The code segment register expands the addressing range to 40-bits.

Requiring that the stack alignment be long-words (32-bits) greatly simplifies the state machine for a number of instructions such as RTS or RTE which then don’t have to worry about unaligned data spanning stack words. I think I will force the stack to always be long-word aligned, but this break compatibility with the original 68k.

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


Tue Aug 25, 2020 4:11 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1442
Location: Canada
Fixed up the cross-assembler to accept a notation used by the VBCC compiler. The assembler croaked on the following line:

l19 reg d2/d3/d4

It’s a label l19 followed by the ‘reg’ keyword followed by a register list. The purpose is to define the label as having the value of the register list. It’s similar to an equate. It’s useful to define the register list as a label when the register list isn’t known at compile time. It allows writing a movem.l as movem.l l19,-(a7) for instance. Where l19 is really a list. There were some hoops to jump through to get the assembler to recognize this syntax.

The FT68000 is pretty much source code compatible with a 68000. I think the VBCC compiler can be used to compile ‘C’ code for this with relatively few changes required. The cross assembler is required however as the object code differs; the byte order is different for constants as an example.

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


Wed Aug 26, 2020 4:15 am WWW
 [ 24 posts ]  Go to page Previous  1, 2

Who is online

Users browsing this forum: CCBot and 0 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