I doubt there will be enough bandwidth in the NatAmi's PCI card slot to provide adequate support for a GFX card.  Also, the SyncZorro slot allows replacing the soft-core with a real 68060 if, for example, an MMU is needed.  The point of the matter is running Amiga software.  No GFX card can adequately well emulate the Amiga chipsets to run most of the software written for the early Amigas.

Back on the subject of naming, just pick something and be consistant.  If you need an alias or macro to be backward compatible then so be it.

But that's rather an argument against assembly.

Matt Hey wrote:

Should an advanced compiler try to use a 68k address register for general purpose use?

An advanced compiler should evaluate all the register allocations possible and should pick the one that fits best to the compiler options, namely either make the code as small as possible, or make the code as fast as possible. Whether that implies that An is used as GP register is really up to the compiler.

Matt Hey wrote:

ThoR advocates high level languages but would he have been as prolific on the Amiga if the assembler was more difficult to read and debug?

Probably not. Because I was starting from the wrong end, I have to admit. Ok, not quite. The story goes a little bit different. I started with BASIC (as probably anyone else at this age) but found it too slow to be of much use. Thus, I learned assembly - that was back then on the 6502. There were no fast high level computer languages, no compilers, not a trace of a useable C compiler, and the other available languages were either scary or exotic. (Does anyone remember Action! ?). Thus, it seemed natural to use assembly on the Amiga as well.  Looking back, this was an unwise choice for several projects, and only the right choice for very few of them.

ViCNEd should have been in C. mmulib and COP are set right in assembly, but these are probably the only projects that are.

You become wiser when you get older.

Matt Hey wrote:

Most languages provide aliases and renaming. It would be better to start with a good name in the first place if we could come to a consensus as to what that is. I would like to hide the .W sign extension of OPA.W <ea>,An instructions now that we added similar support for data registers which is transparent. It makes the ISA more consistent and readable. It would probably require renaming MOVEA.W to MVS.W (or whatever name we decide) also.

Heck, I don't know. I believe all the names are useless and do not express the intend correctly. Does anyone know the Analog Devices Blackfin DSPs? They have a very nice assembler language. Ported back to the 68K, move.l d0,d1 would there be written as d0 = d1;
and add.l d0,d4 simply by d4 += d0; Ditto for "lsl.l #2 d0", which translates to d0 <<= 2;

Simple, efficient and to the point. Avoid cryptic mnemonics when possible.

Greetings,
Thomas

Using my knowledge of Linguistics, Mathematics, English, Marketing, Associative Memory, Mnemonics and possibly other things of dubious value I have calculated the only correct answer to be:

18) MOVESEX / MOVEZEX

Since the opcode performs a MOVE the first 4 letters (prefix) must be MOVE, in keeping with the English language, Legacy Motorola mnemonics and human memory. 

Using MOVE as the prefix also makes it easier for newbs to learn.  Newbs are our friends.  A Newb who keeps getting pwned all the time by intentionally cryptic mnemonics will get discouraged and quit.  Newbs need a helping hand from all us oldsk00l harc0re megac0derz.

So that only leaves deciding what should the suffix be.

Concatenating 2 words together always produces a final product that is easier to remember, easier to spell and easier to pronounce than simply connecting strange combinations of letters together.

So my scientific calculations produced the result of adding SEX / ZEX onto the end.

Everyone can remember that SEX = Sign EXtend and ZEX = Zero EXtend.

Everyone can read, spell and pronounce MOVESEX and MOVEZEX.

From a marketing standpoint, the 680x0 ISA now has more sex than other ISAs thus making it "the kewlest ISA evar!!!!111" :D

I did not "join the debate" earlier, as for me there is nothing to debate.

In my code the only correct mnemonics allowed will be MOVESEX / MOVEZEX.  You may use whatever mnemonic you want in your own code.  You can call them GRANDPA.L and GRANDMA.L in your own code for all I care, you'll just be doing it wrong. :)

If I have to issue my own 680x0 ISA document then I will do so.

I now formally ask my esteemed colleague Mr. Matt Hey to move us on to the next item that needs to be debated.

That's simply too long. One shouldn't need an editor with command completion in order to avoid carpal tunnel. Doing long, overly descriptive mnemonics is something best left to Intel x86 instruction extensions... :)

I now formally ask my esteemed colleague Mr. Matt Hey to move us on to the next item that needs to be debated.

Agree.

or

B: Always type with ur wrists very straight.  Always mouse with straight wrists.  Typing with keyboard in ur lap is a VERY good idea because u don't want ur elbows bent 2 much.

Wear some loose wrist braces to always remind u to keep ur wrists straight.

NEVER use any made in China keyboard.  Or any other high impact keyboard.

ONLY use keyboards with spring switches.  I mean the kind where the springs absorb the shock of ur typing and there is no impact of key striking an immovable surface.  Some old Amiga keyboards had these.  They were called Cherry-Switch keyboards.

NEVER EVER do "finger curls" or "wrist curls".  (doing weightlifting exercises with ur fingers or wrists is an absolute NO NO.)

How about MO'SEX and MO'ZEX? Anyone should be able to remember that...

A line should be using a 32 bit instruction word.
I would like to see 3 op instructions like saturation and such on this line.
Another would be 64bit instructions with a slight twist.

This can be done in two ways like Megol said with a single pipeline multi stage.
Or like I said by chaining the two pipelines of super scalar CPU single stage.

Either has it's perks and cons, this is op to the implementer how to do it.

For most operations we should use a double source in this area which does not get altered and a single destination which could be a 3rd source and destination, or really just a destination register.

For things like saturation this mean you can have a constant loaded in a register and used as one of the sources.

(Just some thoughts)
I wonder if a prefix scheme could be worth it anyway, at least as a complement. Just supporting one prefix should be relatively inexpensive to detect and decode in parallel with the following instruction.

0111REG1nnnnnnnn have at least 8 bits free for encoding extensions (11 bits if the register specifier isn't needed).
As an example:
0111REG1rxyzsnnn

Could support 3 operand instructions, increase the number of registers to 16 data and 16 address registers, support 64 bit instructions (s=size bit) and other things. It would allow future expansion and instruction specific hints too.

An instruction without prefix is treated as having a 0111DST100000000 prefix (where DST=destination comes from the instruction itself).

The rxyz bits are treated as the fourth bit of register number, the register field REG is extended to rREG and the rest are used to extend registers specified in the following instruction.

s=1 and operation size (from the following instruction) = long -> 64 bit operation (possibly trapping if not in 64 bit mode).
s=1 & opsize=word -> word size operation with zero filling of the upper 48 bit to avoid partial register problems.
s=1 & opsize=byte -> word size operation wt. zero filling of upper 56 bits.
s=0 & opsize=long always zero the upper 32 bits. This is also what long operations without a prefix would do.

Just as AMD64 this have the nice property of extending the available registers which could make 64 bit capable code a bit faster, possibly counteract the impact of data size enlargement.

Or is this a complete brain fart on my behalf....?

1) an <ea> for one of the sources to allow immediates
2) allow an address or data register for a source
3) have a bit to toggle on/off condition code updating

I think it should be limited to:

1) modifying 16 bit encodings only
2) using existing encoding space not including A-line or F-line
3) longword, word and byte sizes only
4) existing registers only

There is plenty of existing encoding space to do this without using A-line. I doubt that using A-line would offer a significant advantage. A saturation bit would probably be a good idea. It might allow SATS/SATU to be dropped in that case. I think it would add a fair amount more complexity, require a few more LEs and be significantly more work that Jens and other 68kF implementers would have to do :/. I would want hardware guys involved to make sure any encoding and features are optimal. I think it could be added on an evaluation basis but it would probably be a low priority.

I still do not like 64 bit in the integer units (SIMD or FPU are fine) or adding more registers in the integer units. I think these would increase the logic size (LEs) of our processor significantly without adding much usable performance and likely add incompatibilities. They would make it more difficult to comply with 68kF2. Even the prefix idea may turn off some implementers. There could be a 68kF3 but I would rather keep the highest standard conservative and simple until we have someone implementing/evaluating 68kF2.

 

Marcel Verdaasdonk wrote:

5.)A-line instructions should not cause a fetch beyond what the second word requires.(first word should only contain Dn and An)

 
  The prefix and the common 16 bit instruction would probably be fetched at the same time. I expect they would be treated as one 32 bit instruction.
 
 

Marcel Verdaasdonk wrote:

6.)Do never add a different meaning to the second word then it already has in the 'current' ISA.(Prevent conflicting instructions)

 
  The prefix would no longer be a prefix but rather a new instruction in that case.
 
 

Marcel Verdaasdonk wrote:

7.)Do not add operations that can be done with two ASM instructions requiring the same amount of cycles this is a waste of Opcode space.

 
  It could still be useful when out of registers or when the condition codes is not wanted for example. It would really be up to the programmer or compiler to choose the most advantageous instructions. It would be better to use 2 op when possible.
 
 

Marcel Verdaasdonk wrote:

8.)The First word should not effect the addressing modes of the second word(This is very important for the decoder stage, and Deep sub's current pipeline design)

 
  This goes along with your option #6.
 

OpenOffice Writer
EXTERNAL LINK   
 
PDF
EXTERNAL LINK   
 
html
EXTERNAL LINK 

I didn't add an addressing mode with extended shifts. This would be slower especially in an fpga. There would be several ways to implement it depending on how many shifts were added and what is best for performance. We can always make changes. I hope everything is more understandable than the original 68000PRM in regards to addressing modes. One potential misunderstanding is whether <ea> is an address to memory and only applies to indirect addressing modes (true addressing modes) or whether it's the data used by the <ea>. Any suggestions or ideas are welcome as usual.

So Instructions need to be long word aligned now?