moveq   #%01010101,d0 ;clears Z flag in condition codes
   btst d0,#%11010111  ;should set Z flag
   bne .skip
   bchg.b #1,$bfe001   ;Toggle the power LED if Z flag set
  .skip:
   rts
  

btst #%11010111,d0

but a

btst d0,#%11010111

which is a different instruction. The btst instruction uses the bit number encoded in the source (left operant, d0) and tests whether this bit is set in the target EA, which is now immediate. That is, the Z is set if and only if d0 modulo 8 equals 3 or 5.

Would you be less confused if the program would look like this?

btst d0,Data(PC)

with

Data: dc.b %11010111

See? That's doing exactly the same. Nothing super-hidden, super-cool, super-special. Again, btst is documented (and so is this variant) in the MC68K Programmers Reference manual, available online here:

EXTERNAL LINK 
on page 166. Plain old stupid btst.

     moveq   #%01010101,d0 ;clears Z flag in condition codes
     btst d0,#%11010111  ;should set Z flag
     bne .skip
     bchg.b #1,$bfe001   ;Toggle the power LED if Z flag set
    .skip:
     rts
    

     moveq   #%01010101,d0 ;clears Z flag in condition codes
     btst d0,#%11010111  ;should set Z flag
     bne .skip
     bchg.b #1,$bfe001   ;Toggle the power LED if Z flag set
    .skip:
     rts
    

   moveq   #%01010101,d0 ;clears Z flag in condition codes
   btst d0,#%11010111  ;should set Z flag
   bne .skip
   bchg.b #1,$bfe001   ;Toggle the power LED if Z flag set
  .skip:
   rts
  

The definition in the manual say that BTST D0, IMM
Is 8 bit wide (as the destination isn't a register). "When a data register is the destination, any of the 32 bits can be specified by a modulo 32- bit number. When a memory location is the destination, the operation is a byte operation, and the bit number is modulo 8"
The bit number specifies the LSb as zero (1<<(D0 & 0x7)) "In all cases, bit zero refers to the least significant bit"
Sets the Z flag if the tested bit is zero: CC_Z=!((1<<(D0 & 0x7))&IMM) "Z - set if the bit tested is zero; cleared otherwise"

I don't see where the confusion comes from?

How about this crazy proposal:

We have one Bit free in the Full Extension Word  (Bit3).
How about we use this bit to disable the memory fetch.

Then you could do this:

ADD.L !1234(A0,D0*2),D2

This instruction would calculate the EA and NOT do the memory fetch but pass the address of the EA instead into the ALU - which would use it and calculate on it.

Crazy enough?
Flexible enough to create a new world of hacks?

Effectively, TEAM NATAMI is now designing the rest of 680x0 technology for however long it's possible to advance!!!!!

Well ....
Its clear that making two Data Registers available would be nice form a programmers points of view - but we need to explain this clearly.

The ALU is several clocks in the pipeline below the EA Unit.

This means if zou use a DATA register in the EA - then this DATA register does NOT have to be written to by the ALU for several clocks - OR you will create a slow bubble in the pipeline.

This means code like this:
ADDQ #1,D0
MOVE (A0,D0),D2

This will run VERY slow as between both instructions several clocks of bubbles will be forced.

I like it a lot. Maybe this idea can even be extended over time, to allow explicit control over cache as well as register?  Just thinking...

I like this proposal a lot BTW. :)

A new pattern in I/IS is better to introduce the Gunnar's proposal (which is useful too!).

But frankly if this mode is useful should be investigated beforehand.
How useful do we think is this mode in real live?
Can I compiler make proper use of this?

The proposed hack could most simple be done by setting the same flag. This makes adding this mode is quite simply.
 
The question for me is DOES IT MAKE SENSE?
Can someone see a real benefit of this mode?

We could then do stuff like that:

AND.L {A0 + A1*2},D0
MULS.L {12345678 + A0 + A1*4},D1

Is this just "Cool" or really useful?

Gunnar von Boehn wrote:

Well this can depend on the implementation.   Currently LEA sets a "suppress-memory-access-flag".     The proposed hack could most simple be done by setting the same flag. This makes adding this mode is quite simply.     The question for me is DOES IT MAKE SENSE?   Can someone see a real benefit of this mode?       We could then do stuff like that:     AND.L {A0 + A1*2},D0   MULS.L {12345678 + A0 + A1*4},D1     Is this just "Cool" or really useful?

Does it make sense ? Is it cool or really useful ?

Well, to answer these, the ones who proposed them should write a whole routine, for a real life's case, showing how it's a saviour - and then, of course, post it here :)

For me, either versions do not seem useful but i may be wrong.

2) Use the above encoding to instead add 8 more DATA registers.
This would allow to have 16 data registers + 8 Address register.
This can be encoded without instruction grow.

This option would seperate the AN and DN more cleanly but increase the Data register which many will find useful.
 
 
3) Use an unused bit encoding of the FULL EXTENSION WORD to enable address register update.
 
This would enable this:
  Ex: MOVE 1234(A0,D0*2)!,D0  -- would store the EA in A0

This would make certain memory operations save extra instruction to update the pointer.
As the CPU has this path already this is basically free to add.
 
 
4) Use an unused bit encoding of the FULL EXTENSION WORD to allow passing the EA to the ALU - without doing a memory access.
 
  This would allow combining the result of a LEA with any ALU operation.
  Ex: OR {A0,D0},D2

This like a special case optimization.
The drawback of this mode is the latency dependancy between the banks as their updates are done in different pipeline stages.
This might make it difficult to support this in a compiler.
 

5) Another proposed option would be adding more ADDRESS Registers.
This could relative simply be done be using PREFIX words.
Without using PREFIX words this is tricky. By using Bit3 in the FULL EXTENTION WORD someone could add cheat mode which allows doubling the registers. This could be combined with the option to add 8 more Dataregisters ...

 
 
6) PREFIX WORDS
We can also use PREFIX WORDS to make a single 68K instruction do more work. We partly do this already by FUSING certain combinations.
E.g right now we do:
  MOVEQ #5,D2
  ADD.L D1,D2
 
This fuses two operations into one more powerful.
This could be enhanced by doing even more complex operations.
This would make the code denser and enhance our possibilities to use all of the powerful 070 ALU per clock.
 
Very "strong" instruction are:
ADDM (An)+,(Am)+

This instruction does 2 memory loads, 1 memory update, 2 AE calcualations, 2 Address register updates, 1 Alu operation.

The 070 design is tweaked to be able to do this in 1 single cycle.
Therefore we have to have all units needed for this.
By strengthening more instructions to do this much work we can improve the power per clock of our system

 
 
I think we all see that there is some ideas and potential for strengthening the CORE....
 
  Which benefits do you see?