Moving off-topic discussion from viewtopic.php?t=1482&start=15 here...



I've not worked with ARM, but so far as I've been able to compare in my assembly language experience, not one RISC architecture ever was as convenient to code for as the 68K.

I'd be interested in knowing what things you think the ARM does better than the 68K.

(That being said, I've thoroughly enjoyed MIPS and PowerPC programming to a very large extent! Please don't take this as a challenge against RISC because of 68K favoritism.)

I'll just cover those things I really like about ARM in general

1. load/store multiple of any arbitrary register combination
Yes, thats right. One can do "STM r0, {r0-r15}" if they want to and save every register. LDM is the same.

2. Address updates available for every memory instruction
Reusing STM from above, "STM r0!, {r1-r15}", will write the final address to r0 (I've forgotten the exact specifics here). Pretty much every memory op supports this

3. The stack is my territory, and mine alone
The processor will never touch the stack. I don't have to deal with processor built stack frames. This greatly simplifies some things

4. Pre-shifts available on all basic ALU instructions
(Where "basic ALU" is defined as pretty much everything except MUL. ARM doesn't have division)

This is an incredibly useful feature, though it does make the instructions occasionally look like huge monstrosities! It also means that ARM's ADD instruction can double for most architecture's LEA.

5. Three operand instruction set
Well, that one should be reasonably clear

6. No mode flags (or those which exist are implicit)
For example, while there are both the ARM and Thumb instruction sets, they're designated by the least significant bit of the branch target address.
The BX/BLX instructions automatically move this bit into the current program status register (CPSR)

7. PC is in the register file
Yes, you can do "MOV pc, lr" (this is the traditional way to return), and can use the ALU operations for relative branches.

(Caveat: On machines prior to ARMv7 [ARM11 and older processors], these instructions will not transition to/from Thumb mode and the result of loading the least significant bits of PC is Unpredictable. ARMv7 makes them interwork properly with Thumb)

(By the way - when ARM say Unpredictable they mean "May raise a trap, may do something completely unrelated, may be a NOP - behaviour is undefined except that it cannot cause a security hole" and be redefined by future revisions)

Its not an really an OS convention, more of a necessity. The 390 doesn't have relative addressing. All memory access for data or execution are calculated from the value of a base register plus a 12 bit positive displacement (plus an optional index register in some instructions). When your code begins execution it must establish a base register for itself for any subsequent branches to work. This is why 390 assembly routines usually start with a sequence like

This usage of BALR loads the address of the next instruction in register 11 and then the USING tells the assembler so it can calculate the displacements for branches in the following code section. If you don't set the base register up properly then the next jump can go off randomly.

I used to program an ICL 4/30 which was a very cut down IBM 360 with 64K of ferrite core memory when I was a kid (see http://en.wikipedia.org/wiki/English_Electric_System_4). Our machine didn't have the full set of instructions - In the back of the CPU there was a lot of cards that handled the instruction decoding and lots of spaces where we didn't have any cards. The machine would interrupt if you tried to execute an missing instruction. I extended our operating system to catch the interrupt and emulate the missing ones.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Has the 68K family of CPU's reached "end of life"? I would have liked to experiment with the 68000, and then the 68020...

When I was still in high school, I remember Motorola introduced the 68000 to outpace the 6500 series. I was intimidated by the number of pins, plus not having enough money as a teenager to afford a 68K system to develop on, my friend and I stuck with the C64 and VIC20 and their well documented expansion port, unlike the original Macintosh. Which in typical Apple fashion had no documentation at all for "developers". Translate, hobbyists? I think back then, I choose my College (Drexel U.), based on the fact that it was mandatory to buy the original Mac. Anyway, I digress...

The reason I post is because I am curious if those 68000 and 68020 IC's can still be purchased from anywhere besides ebay?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

68000s are still in pretty good volume production. The newer chips aren't NRND yet, but they're hella costly to the point you know Freescale are making them because they're embedded in some military aircraft or similar.

If you want to experiment with 68k, your best bet is ColdFire (which is a stripped down version - more RISC like addressing modes and such)

Yes, the 68000 and its successors are officially end-of-life. Coldfire has replaced the line, having a more streamlined instruction set.



I doubt that was their motive. The 6809 seems a more likely candidate for competing with the 6500 series.



That's because the original Macintosh had no expansion port. Unlike the Apple II series, which was documented extremely well to encourage development, Jobs saw the Macintosh as an appliance, not an experimenter's platform. Therefore, he felt the original Macintosh deserved no expansion capabilities, intending to sell upgraded machines over time as a regular revenue stream.



Not affordably.

However, if you've got an FPGA handy, I believe opencores.org has several free 68000 implementations to choose from. See:

http://opencores.org/project,ao68000

While this doesn't appear to be the best possible choice, the page links to other OpenCores implementations of the CPU, thus serving as a nice index page.

And if you ask me, I think that's how it should always be. Having to deal with relocations in code (whether re-assembling or recompiling, or having to deal with them in loaders and linkers) just plain sucks.

68000 -- check. movem.l d0-d7/a0-a6,-(a7) is a common occurrence in 68K listings.



68000 check. Register pre-decrement and post-increment works in any effective address, including move-multiple, as indicated above.

However, base+offset will not cause a register to be updated (a la PowerPC). I can't see a use for such a thing, never having had a need to even use LEA.L before. (I have had to use LEA on x86 to overcome a register shortage, and the 3-operand add it provides was nice in a jiffy.)



The 68000 has a hardware stack assigned to register A7. However, seven other address registers exist, all of which are capable of serving as user-supplied stacks.

The hardware imposes a stack frame only on the supervisor stack, which is the domain of the OS kernel alone. The CPU does push a return address on the A7-stack when invoking BSR or JSR, but otherwise, the stack is your domain as well. Except for leaf subroutines, though, not having to manually stack the PC is awfully convenient.



I've not noticed, personally. Working with the MIPS architecture, I found no difference in preference to MOV EAX,EBX; ADD EAX,ECX over ADD R2,R1,R0. To some extent, I prefer the 2-operand forms, because then I don't have to keep specifying the same register over and over again in subsequent instructions.



Contradictory -- clearly there is a mode flag here. Perhaps you meant that no instructions to manually set or clear this flag exists? If so, I can concede that's nice, when compared against the 65816. But the 68000 also lacks such instructions, too.



Unfortunately, this consumes two CPU registers (the PC and the link register) which you cannot use for anything else. Also, putting the PC in the register file itself makes it difficult to optimize the micro-architecture for very high performance (by which, I mean, something comparing to a POWER-architecture RISC). I won't say it's impossible, but I will say it'll take transistors to pull it off.

Not that it would be particularly efficient, but if someone just wanted the conveniences of the 68000's assembly-language instructions as mentioned earlier, you could get most of this on the 6502 or '816 with macros. And although the PC isn't in the register file, even the "MOV pc, lr" above could be done on the '816 in a macro with PER, PLA, STA, 16 clocks total with A in 16-bit mode. PER allows an offset too, and STA has lots of possible addressing modes. It could be done on the 6502 also but would be messier.

You can go even more efficiently if you code in Forth. Converting stack code to 65xx-code using zero/direct-page efficiently is, while not easy, doable, and the results will be a whole lot faster (and portable!!) than simply coding with macros.

Its not really that big an issue, performance wise. OK, you have to have some transistors up front to detect writes to PC, but reads are served pretty easy, in the same way they are in any out of order architecture: by renaming the source PC. For in order designs, its even simpler, because PC always points to the next instruction so you can just take the value from the actual PC register.

The major plus is that it gives you very flexible PC relative addressing.

As for the register count: 13 general purpose integer registers is most of the time enough. Its certainly enough to stop you from going to memory all the time. Plus,

Of course, this isn't true of all code; floating point code especially, but the VFP has 32 single precision registers and 32 double precision (of which the first 16 alias two single precision each). The NEON SIMD unit aliases onto these double precision registers (ala MMX, except not modal), but also supports fast floating point (I'd expect the execution resources are shared).

Having PC in the file also means you can do things like this:


Oh, and finally, the big one I missed:
8. Full Predication
Every* instruction can be made conditional. Simply postfix it with the condition you want



Additionally, you select whether the basic arithmetic instructions set flags or not.

* Some system instructions are not possible to predicate because they are encoded by using the bit pattern which would correspond to "if never"

Yes, per-instruction flag update control would be my vote for best feature too. That is one thing I did, very much, enjoy with PowerPC coding.

Also, predication definitely looks interesting. I've known about it for some time, but never had the opportunity to explore its impact on coding.

Just as an example of some coding that I've used in the past (some code I'd written for an Acorn Atom emulator under Acorn's RISC OS in the very dim and distant past), here's (part of) the code for "ADC imm":

MOV temp_a, ra, LSL #24
MOV temp_b, data, LSL #24
TSTS rp, #flag_c
ORRNE temp_a, temp_a, #(&80 << 16)
ORRNE temp_b, temp_b, #(&80 << 16)
ADDS temp_a, temp_a, temp_b
BICPL rp, rp, #flag_n
ORRMI rp, rp, #flag_n
BICVC rp, rp, #flag_v
ORRVS rp, rp, #flag_v
BICNE rp, rp, #flag_z
ORREQ rp, rp, #flag_z
BICCC rp, rp, #flag_c
ORRCS rp, rp, #flag_c
MOV ra, temp_a, LSR #24

In my code, "ra", "rx", "rx" and "rp" are aliases for "A", "X", "Y" and "P", mapping them to ARM registers, "temp_a" and "temp_b" are two further scratchpad ARM registers, and "flag_n", "flag_v", "flag_z" and "flag_c" are constants for bitwise manipulation of the 6502 flags held in "rp"/"P".

The snippet "fiddles" the contents of the emulated 6502 registers, does the "ADC" calculation, then maps the ARM flags back to the emulated 6502 flags; out of the four pairs of "BIC"/"ORR" instructions, one writes its results back to the "rp" register, while the other doesn't (in essence, acts as if it were a "NOP").

HTH,

--Martin

BTW, the ARM lacks a specific "NOP" instruction - "NOP" within ARM assemblers is essentially a directive that is translated to "MOV R0,R0"; this, as it does not have the "S" ("set [flags]") option set, has no effect on registers or flags.

_________________
Martin Penny

.sig in beta - full release to follow.

(PS: "data" is another alias - maps to the 6502's data-bus register.)

_________________
Martin Penny

.sig in beta - full release to follow.