Why is LEA 0x89AB(%A0),%A0 an Illegal Instruction in 68000 assembly
here is the programming card : https://files.fm/u/7pfmqca9
Why is LEA 0x89AB(%A0),%A0 an Illegal Instruction in 68000 assembly?
1 answer

Based on the examples given, I infer that a 16bit immediate is sign extended. From that, I would guess that the 16bit offset in the indexed addressing mode is also signed. Thus, 0x89ab is an invalid offset, because it doesn't fit in a 16bit signed number.
See also questions close to this topic

MSVC inline assembly to GCC (with parameter and return)
inline float sqrt2(float sqr) { float root = 0; __asm { sqrtss xmm0, sqr movss root, xmm0 } return root; }
here is MSVC compilator inline assembly which I want to compile with gcc x86, what I know that gcc inline assembly is getting called with asm("asm here"); but I completely don't know how to include parameter in that, the result is obtained by "=r" I know only.
Which should result in something like that:
asm("sqrtss xmm0, %1\n\t" "movss %0, xmm0" : "=r" (root) : "r" (sqr));

PIC16F877A ADC in assembly: Howto show result on 7 segment display
I am trying to perform analog to digital conversion on PIC16f877a. well the problem is when I am showing my result on led it working fine but when I am showing my result on 7 segment I have some invalid output may be I am unable to convert binary to decimal properly ("for BCD conversion I am using 74ls47") can any one help me. Regards, Haziq.
image is here. enter image description here
RES_VECT CODE 0x0000 ; processor reset vector GOTO START ; go to beginning of program ; TODO ADD INTERRUPTS HERE IF USED CNT0 EQU 0x21 ; MAIN_PROG CODE ; let linker place main program START BSF STATUS,RP0 MOVLW b'00000000' MOVWF TRISB MOVLW b'11110000' MOVWF TRISD MOVLW b'00000001' MOVWF TRISA BCF STATUS,5 MAIN_LOOP CALL ADC_INIT ;INIT ADC MODULE CALL ADC_READ ;READ ANALOG VALUE AND STORE TO ANVAL REGISTER ;OUTPUT ANVAL TO ;================================== GOTO MAIN_LOOP ;======================================================================================== ADC_INIT BSF STATUS,RP0 ;SELECTING BANK 01 FOR ADCON1 REG MOVLW b'00001110' ;LEFT JUSTIFIED, FOcs/8, +VREF=VDD, VREF=VSS, AN0=ANALOG MOVWF ADCON1 BCF STATUS,5 ;GOING BACK TO BANK 00 MOVLW b'010000001' ;FOcs/8, A0=ANALOG INPUT, MOVWF ADCON0 RETURN ;========================================================================================= ADC_READ BCF STATUS,5 ;SELECTING BANK 00 BSF ADCON0, 2 ;START CONVERTION PROCESS (WE SET THE GO BIT) WAIT: BTFSC ADCON0, 2 GOTO WAIT ;WAIT FOR CONVERTION TO FINISH (WAIT FOR GO BIT TO CLEAR) MOVF ADRESH, W ;MOVE ADRESH TO W MOVWF PORTB ;SHOWING 8 MOST SIGNIFICANT BITS OF A/D RESULT MOVLW 0x06 MOVWF CNT0 AGAIN_0: BCF STATUS, C ;WE WANT SHIFT (NOT ROTATE), SO WE CLEAR CARRY RLF ADRESL, 1 ;SHIFT LEFT 6 BITS A/D RESULT HIGH BYTE DECFSZ CNT0 GOTO AGAIN_0 MOVF ADRESL, W ;MOVE ADRESH TO W MOVWF PORTD ;SHOWING 2 LEAST SIGNIFICANT BITS OF A/D RESULT RETURN END

Adaptive sorting algorithms versus sorting networks for sorting a list of 32 random elements
If we are using a sequential machine (parallell comparisons is not possible) where comparisons are made in sequence and and we are looking to minimize the number of processor clock cycles when sorting 32 random elements, should we use a sorting network or an adaptive sorting algorithm?
There are no optimal networks (yet) for n=32 elements. In practical terms, if we want to minimize the number of CPU clock cycles, is it best to divide 32 elements into four sublists of n=8 and apply the optimal sorting network on each sublist, then merge the lists together?
We are obviously working with "average performance" here, because adaptive algorithms can get lucky if we are given an already sorted list.
Crunching the numbers we have the following:
Sorting a list of size n:
Minimum number of comparisons for n=2 is 1.
Minimum number of comparisons for n=4 is 5.
Minimum number of comparisons for n=8 is 19.
Mergin two lists of size n:
Merge two lists of n=2 is 2*n  1 = 3 comparisons
Merge two lists of n=4 is 2*n  1 = 7 comparisons
Merge two lists of n=8 is 2*n  1 = 15 comparisons.
Merge two lists of n=16 is 2*n  1 = 31 comparisons.
Total number of comparisons if we divide n=32 into sixteen n=2 sublists:
 Sorting: 1*16 = 16
 Merge: 3*8 + 7*4 + 15*2 + 31*1 = 113
 Total: 129
Total number of comparisons if we divide n=32 into eight n=4 sublists:
 Sorting: 5*8 = 40
 Merge: 7*4 + 15*2 + 31*1 = 89
 Total: 129
Total number of comparisons if we divide n=32 into four n=8 sublists:
 Sorting: 19*4 = 76
 Merge: 15*2 + 31*1 = 61
 Total: 137
Now one might think it would be better to divide the n=32 elements into n=2 or n=4 sublists since the total number of comparisons is smaller. But mergin requires storing parts of the array "outofplace" which might negate the benefit of less comparisons?
My gut feeling tells me that on average the nonadaptive sorting network is similar to an algorithm in terms of total comparisons but the sorting network wins due to less overhead, am I right?
I am trying to sort n=32 elements in less than 1200 clock cycles on average. I am working on a simple sequential machine with a simple 256 words * 16bit memory and only four registers, so the network/algorithm has to be simple, fast and not require a lot of space. The ALU only has adding, subtracting, one bit shift, one bit rotating, AND, and OR functionality. Memory and ALU operations take a single clock cycle each.

assembly language tricky stuff
If I have:
D0: 8030 02020 A0: 0000 42020 0000 6000 bravo: dc.l 1,2,3,4,5,6,7,8,9,10,11,12
sub.l alpha +15,D0
and How would I get the
move.l (A0),D0

M68000 Assembly, how do I loop a subtraction
I want to make a subtraction loop. I am tasked with finding out the number of $100 bills in a sum. For example, user enters $950. There is 9 one hundred dollar bills in that. What I first did was store the user input in date register 1, and compare it to 100.
cmpi.w #100,D1
I want to basically do "if D1 is less than 100, subtract another 100". How can I achieve this loop? I would like to use the branch greater than and less than instructions but am not sure how.