non load/store architecture?

Sure. The following Z80 instruction for example:

ADD A,(IX+d) Add location (IX+d) to accumulator

"Field Programmable Gate Arrays" (okay, I admit that's an extreme answer, but it is one)

Op 11 Dec 2006 16:27:11 -0800 schreef cs snipped-for-privacy@hotmail.com:

The processor does load the byte from the memory at IX+d. So your assumption is not valid.

--
Coos

CISC? They have things like RS (register-storage) SS (storage-storage) and SI (storage-immediate) instructions. Most also had the load/store and RR (register-register) instructions. For examples look at the IBM System/360 instruction set (or almost any machine pre late 1980's). For one almost devoid of register instructions (it only had two index regs) see the IBM System/3.

No, you are wrong.

The programming model does not feature a load preceding the ADD.

The physical implementation might or might not. It might load the memory contents to a pipeline register for example. Or it might not - it would certainly be simple enough to build a processor which can route the unlatched data bus directly into one of the ALU ports - in fact, most simple designs of the sort that get drawn on blackboards or implemented by students in verilog do exactly that.

If you want to define load/store as any architecture which has to get the data out of memory before it can process it, then you are wierd, and my FPGA joke answer (co-distributed storage and computation) applies.

And actually, in certain varities of simple design, the only way to get data out of memory and into the register file is to send it through the ALU, where you have to ADD the contents of the all-zeros register to it in order to pass it through unmodified.

Thanks ..are there any low end embedded processors. Wondering if its not a bad idea for low end processors ?

dz cs snipped-for-privacy@hotmail.com schrieb:

The decision for a load/store architechure isn't one that can be taken in isolation: it implies a number of general purpose registers and a two or three address architechure. If you go for an accumulator approach which was fashionable twenty or thirty years ago it simply isn't possible. The x86 architechure in particular was first defined about this time.

Another thing is the way you are looking at this. The question to ask is why _go_ for a load/store architechure, not why not. I'm not arguing for a moment that the load/store architechure is without merit, it's just not obvious for the inexperienced. Having arithmetic instructions that can access memory simplifies register assignment for the programmer (or compiler) and if a value is only needed once in a certain area of code, then all other things being equal it has much to commend it. IOW, it's other factors that influence the decision to go load/store and not vice versa.

--
Andrew Smallshaw
andrews@sdf.lonestar.org

The one type that comes to mind is "memory to memory". An example is the IBM 1620, circa early 1960s. This BCD machine had memory addressed as digits, with each location having 6 bits: 1248, flag, and parity. Parity was for error detection and not under user control. Each instruction was 12 digits and had a two-digit opcode, plus two 5-digit operands called P and Q, I think, for destination and source. There was no accumulator.

Most instructions addressed the least significant (highest address) digit of a field. Operations were performed digit by digit, terminated by a flag bit over the most significant digit. An immediate instruction could contain up to a 5 digit operand instead on an address (actually the length could be greater if the Q field didn't contain a flag, but then the immediate operand contain other parts of the instruction and maybe more!).

--
Thad

Another one is exemplified by the P-machine, used by Wirth for the Portable P4 compiler, and in a modified form by me for PascalP. This is a pure stack machine, so that expressions can be translated into RPN at all times. P4 had, IIRC, precisely one load and one store instruction, which operated on the top of stack. PascalP had more, and was easily implemented on an 8080, to the extent that the full ISO standard compiler could run comfortably on an 8080. I included indexing operations, and some other handy opcodes. Another example is the HP3000, which again was not a pure stack machine.

These are much more recent than the IBM 1620.

Remnants of the PascalP system exist on my site (below) including a manual. The rest was lost in a disk crash.

--
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.

One of the most interesting variable instruction length architectures ever designed. It also used lookup tables for all arithmetic. Do you remember the simple recursive copy instruction to clear all core?

One of the best FM-RF music programs was done on the 1620 at Carleton College in Northfield, MN.

Regards,

Michael Grigoni Cybertheque Museum

Ah, the memories..

I used one in school in 1968-9. It ran NCE Fortran, a subset of Fortran II, with only 4 digit integers and some floating point, no strings. We had a card reader and punch, with a couple of IBM Model 29(?) keypunches for creating programs. I remember hitting Reset, Insert, Release, Start, Start on the front panel to start the card reader.

Consoles from IBM 1620's were used as computer consoles in "Colossus, the Forbin Project" in the early seventies.

RB

Boy this post brings up old memories.Thesis time and Fourier transforms before FFT. Tuns of fun.

Just pulled the Reference Summary IBM 1620 Model 1 Data Processing System bookette.

Starts with character coding for this computer

Terminology has changed.

1620 Special features means if you ordered the instruction and paid more its there otherwise its a NOP

Remember math look up tables for add and multiply and all the neat things that could be done changing them. They were memory based accessible by any program.

Timing add for example 21 ADD Fp = Fp + Fq 160 + 80 *(digits in P number) + ( 80* (Digits in P) if the signs of P and Q were different and Q > P)

I didn't make this up. numbers in microseconds. Take two 5 digit numbers ( a bit more than 16 bits) without the extra option of signed differences and size. The fundamental

60 + 80 *(digits in P number) 60 + 80*5 = 460 microseconds with sign and size option add 400 more call it an even ms to add a small numbers (6 digits).

A weekend of computing time to calculate the first 2000 terms of a fibanacci series

Muliply is interesting 560 + 40 * (Digits of Q) + 168 * (digits of P) * (digits of Q) using our 5 digit numbers above

=560 + (40 * 5) + (168 * 5 * 5)

=560 + 200 + 4200

=4960 microseconds

Every once in a while we need to remind ourself about the good old days

Seasons best everyone

w..

accumulator model

Walter, I worked on a 1620 in assembler and in Fortran! Thanks for the info!

Jon

Homework?

There are plenty that "have instructions other than load/store than can access the memory".

Anything that has INC/DEC/DJNZ of a direct memory address qualifies. So that gets you 8051, 6805, 68HC11, Z8, Zeno, PIC18?, Coldfire, etc

If you want interesting special cases, look at

** the Intel 8096, that had no ACC, all operations were Reg-Reg, but it used 256 registers ** Any RISC Reg-Reg design, that also has a register frame pointer The C166, and Z8 ( and IIRC, some Sparcs?) have these, which allow the reg-reg opcodes to work into any window of larger SRAM.

Q: is that now accessing register, or memory ?

-jg

I've heard them called "memory/data", as in this quote from John Bayko's Great Microprocessors page at

'Another note on terminology - because of the muddling of the term "RISC" by marketroids, I've avoided using those terms here to refer to architectures. And anyway, there are in fact four architecture families, not two. So I use "memory-data" and "load-store" to refer to CISC and RISC architectures. This file is not intended as a reference work, though all attempts (well, many attempts) have been made to ensure its accuracy. It includes material from text books, magazine articles and papers, authoritative descriptions and half remembered folklore from obscure sources (and net.people who I'd like to thank for their many helpful comments). As such, it has no bibliography or list of references.'

See also Appendix A:

The page is great stuff, though seems not much updated now. --mpa

CISC, i.e. having arithmetic instructions that can access memory, i.e. the x86 architecture we love to hate, is hard to optimize. Your statement, "simplifies register assignment for (the compiler)" only applies if you have no intention of producing optimal code.

One of the liabilities of RISC, i.e. load/store, is that programmers don't tend to write code with any kind of load/store discipline. They write whatever the hell they feel like writing. If it's the garden variety industrial "butt code," it will contain sequences of memory accesses that cannot be changed. At least, that the compiler can't prove are safe to change. Programmers can write great code on a RISC architecture if they're RISC-aware. LOAD everything up, do the math, STORE the results. But generally they aren't RISC-aware, and don't want to be.

Especially in a PC marketplace dominated by the x86. At DEC, we ran into this issue all the time when porting device driver code to the DEC Alpha. It's also why the Alpha's x86 emulation was never all that great. x86 code, in general, simply couldn't be re-scheduled in RISC load/store fashion. The Alpha may have been the world's best CPU in its day, but it didn't have a commensurately kickbutt memory controller, so we suffered.

x86 is still here and the Alpha's dead. This is a clear case of "Worse Is Better." That is, you spread your marketshare by being 1st with the quck-n-dirty version. Also, if your inelegant solution runs on average machines, you spread faster. Those who hold out for "Better Is Better" tend to marginalize their marketshare. Look at what DEC was: great engineering company, couldn't market its way out of a paper bag. Look at the Wintel hegemony: still with us today, still has the same business model of "Worse Is Better."

Cheers, Brandon Van Every

There were a couple. Let's see, you could use TFM 00010 00000 (Transfer Field iMmeidate), which was 160001000000. That would start copying address 11 to address 10, then 10 to 9, etc., wrapping around memory looking for a terminating flag that it would never find.

I believe there was another that used the Transmit Record, 31000700008 (or something similar), which would copy in an ascending order looking in vain for a record mark.

After hitting Release and Run to let it run, you had to Stop to do anything else.

I wrote a life program for the IBM 1620 after reading the original article in Scientific American, which never mentioned a computer.

Fun machine!

--
Thad