Die space for m68k on FPGA?

[ChaosLord]

I am interested in how much space 68020+ takes.

How much space 68050/68070 was taking was written many times on Natami forums.  It was always a moving target as things got changed.  I can't remember what the numbers were.

There are 3 main numbers:
LE: Logic Elements
SRAM: How many SRAM banks it uses.
Multipliers: Many FGPA chips have built-in multipliers you can use so u don't have to waste LE on them.

[ChaosLord]

020 is just an 000 with 32-bit datapaths, a small L1 cache and a barrel shifter and a few new instructions and a few new addressing modes.  It is more complex, sure.  But I am still interested to know how many more LE it takes over a plain jane 000

[ChaosLord]

better would be to add specific instructions to the 68k that help with emulation of other processors.

+99999

[ChaosLord]

68060 can despatch two instructions at the same time, I don't think it decodes them at the same time.

The M68060 dispatches, decodes, executes, completes and writes the results of 2 instructions at the same time.

This applies to most of the common simple simple instructions.

It does not apply to gigantic complicated instructions or rare instructions.

Furthermore, it does 3 instructions at the same time, as long as 1 of the instructions is a correctly predicted branch.   Loops are common structures of computer programming.  The branch at the bottom of the loop will be correctly predicted the 2nd thru the nth times it is executed.

I don't know if it will correctly predict the LOOP branch the 1st time it is encountered.  But if you have a loop from 1 to 1000 then it will be correctly predicted 999 times out of 1000 which is a fairly good rate.

[ChaosLord]

Add some new instructions.

Which will cause incompatabilities..

Intell adds new instructions all the time.

Yet I never see you posting on Intel forums "omg!  Its incompatible!"

p.s. Never ever ever ever buy a Rosewill keyboard.  This stupid thing @#?!@>#$ up every single msg I type.  GRRRR.  It only worked for 25 days.  Since then its been complete crap.

[ChaosLord]

Yeah, any design that allows you to write software that won't run on a real amiga is very bad thing. Anyone who wants something new would find a PC more suitable,

You said "any design that allows you to write software that won't run on a real amiga is very bad thing."

This means PCs are bad because its a design "that allows you to write software that won't run on a real amiga"

Then you tell ppl to buy a PC.

You are not making any sense.

[ChaosLord]

The FPGA used in Replay is not likely to have the die space to handle 386 + m68k at the same time.

386s are dirt cheap.  NewEgg was selling 2Ghz Celerons with a free springloaded keyboard for $25.00 last week.

As for 386 it has been discussed before. The size is just too big to be practical. It's way better to use the ASIC 386 until moores law makes it feasable.

[ChaosLord]

DosBox with 68k Dynamic Recompilation should be able to achieve 386 emulation speeds on a fast 68060 or fpga 68k CPU. The bonus is that the Amiga can multitask at the same time kind of like the advantage of ShapeShifter over a real 68k Macintosh.

+9999

An enhanced fpga 68k CPU could support faster emulation of x86 by providing some useful instructions and addressing modes that the x86 has but the 68k does not.

Adding new instructions is easy.  Adding new addressing modes.... uhmm... you would just have to say that certain instructions are hardwired for this new addressing mode that you want?

[ChaosLord]

No. I want to add the new addressing modes for all 68k effective addresses (EAs).

Its been such a long time since I studied the addressing mode bits... I thought they were all used up?  How will u encode a new universal addressing mode?

The addressing mode in question and used in DosBox is base register update which the 68k does not have. I represent it in the 68kF docs as (bd,An,Rn*Scale)! with the explanation point at the end specifying to update the base register An with the calculated value. The EA is already calculated so there is little additional overhead.

"The EA is already calculated so there is little additional overhead."
hmmm.. maybe...
Due to the pipelined structure... it could be troublesome to code that in.  I am sure it can be done... with some trickery.  

 ARM also has this addressing mode and probably some other processors making emulation easier. The 68k addressing mode would be much more flexible and usable than the x86 addressing mode because the 68k has general purpose registers and more of them.

You have convinced me that it is a good thing to add in.

But the devil is in the details

The first thing Jens is going to say is "it messes up the pipeline structure and adds more complexity to the processing and I have to add another secret internal register to hold and forward the results and..."

[ChaosLord]

move -(An),Dn
for instance, already updates the address register with the calculated value. So it shouldn't be too much trouble.

Good point!

They already forward results from the EA unit into an Address register after the instruction is complete.

There may be a limitation of requiring it to be an Address register in order not to stall the pipeline.  But no problems.

 It's the encoding that worries me, however I have the Motorola reference manual in front of me and it states that IS-I/IS values of 0100 and 1100-1111 are "reserved".

I seem to have forgotten what IS-I/IS means?

In any case: "Reserved" means "Reserved so we can use them".

[ChaosLord]

There is room to add addressing modes with scale > *8

Ah yes!  I remember that.  I still want my *32 scalefactors!
Seriously I do want them.