Re: Archiving otrona attache disks
The 96tpi ones are 800K, and should be treated like any other "Quad Density" CP/M disk. On Tue, 24 Aug 2021, geneb via cctech wrote: Just for my own curiosity, can a "typical" high-density 5.25" drive correctly image a 96tpi disk? USUALLY. Either the drive needs to be able to switch to 300 RPM, OR the FDC needs to support 300bit per second data transfer rate, (same as what was required for routine reading of 360K disks in the 1.2M drive.) BUT, it needs to NOT automagically engage a double-step "feature". One of my primary test machines was a "REAL" 5170. It worked OK for "720K" 96tpi disks (what some companies called "quad density") 'Course, use of a 5150/5160 with a "low density" 96tpi drive, such as Shugart/Panasonic/Matsushita 465, Mitsubishi 4853, Teac 55F, Tandon TM100-4, or similar avoids that particular potential (but not common) BIOS issue.
Re: Extremely CISC instructions
Another interesting architecture, not sure if it quite fits your question: the orthogonal computer. You could think of that as vector processor with serial arithmetic -- a cross of a Cray-1 and a PDP-8/S :-) It was invented in the 1960s by William Shooman, and sold for a time by Sanders Associates. The Goodyear STARAN is somewhat different but inspired by that machine. paul
CWVG
Back in the 2007 time frame, Andrew Lynch had written a utility to read Vector Graphic hard-sectored diskettes on a Catweasel board. Called "CWVG", does anyone have a copy of the program? Mike Loewen mloe...@cpumagic.scol.pa.us Old Technology http://q7.neurotica.com/Oldtech/
Re: Extremely CISC instructions
On Tue, 2021-08-24 at 11:11 -0700, Chuck Guzis via cctalk wrote: > On 8/24/21 10:40 AM, Van Snyder via cctalk wrote: > > > That's the BLAS SAXPY (or DAXPY) routine, a fundamental step in > > Gaussian elimination. > > Speaking of which, do any specimens of the Saxpy Matrix-1 still > exist? > Saxpy Computer was a brief flash in the supercomputing universe; fell > onto bad times when a former employee was caught selling secrets to > the > Soviets. Afterward, the company went into bankruptcy, if memory > serves, sometime in the 1980s. > > SAXPY was a program in the LINPACK suite, and well known to FORTRAN > benchmarkers. Ref: > http://www.netlib.org/lapack/explore-3.1.1-html/saxpy.f.html Since > LINPACK could well mean the difference between a sale and a "thanks > for > trying", it received a lot of attention. I was at the first Supercomputing conference at the Westin Bonaventure Hotel in Los Angeles, with two of the four authors of the first BLAS paper -- Charles Lawson and Fred Krogh. Fred asked the PR flack for SAXPY whether he knew the origin of his company's name. He did not. Richard Hanson had recently moved from the Jet Propulsion Laboratory to Sandia National Laboratory in Albuquerque. I lost track of Dave Kincaid. Sadly, Lawson and Hanson have passed away. > > --Chuck > >
Re: Extremely CISC instructions
On 8/23/2021 8:51 PM, Van Snyder via cctech wrote: On Tue, 2021-08-24 at 01:38 +0100, Tom Stepleton via cctalk wrote: For the sake of illustration to folks who are not necessarily used to thinking about what computers do at the machine code level, I'm interested in collecting examples of single instructions for any CPU architecture that are unusually prolific in one way or another. IBM 1401 was a character-by-character machine, so most operations had costs proportional to field length. One especially expensive (but very useful) operation was "move characters and edit." Assuming a 17-character control word has been loaded to the destination, e.g. "$ , 0. &CR&**" to edit a data field "00257426" with a "negative" zone bit on the low- order digit, producing "$ 2,574.26 CR **" requires 41 memory accesses (including seven to fetch the instruction) -- 0.4715 milliseconds. See pages 41-43 at http://www.bitsavers.org/pdf/ibm/1401/A24-1403-5_1401_Reference_Apr62.pdf On a machine where the "Expanded Print Edit Feature" was added, the instruction cost even more. For example, the "Floating Dollar Sign" moves the dollar sign to immediately to the left of the most significant digit. This (and asterisk protection) was to prevent somebody from adding digits between a left-justified dollar sign and leading digits on printed checks. The above edit would cost two more memory cycles. If the datum had had more leading zeroes, even more cycles would have been required. Useful for COBOL. ;) See pages 82-84. Another expensive instruction was the simpler "move characters and suppress zeros" instruction. See page 38. Along those same lines, the IBM 1410 had what the 1401 had, plus: http://www.bitsavers.org/pdf/ibm/1410/A22-0526-3_1410_princOps.pdf - A very useful table lookup instruction (pp 29-31) - At least 56 ways to move data, depending upon the "d" character (op modifier) specified (pp 25-28) - A scan that could stop at various terminators without moving data (pp 26-27) JRJ
Re: Extremely CISC instructions
The Hitachi SH4 has a set of pipelineable vector instructions that work on 4x4 and 4x1 length vectors (implemented as 2 sets of 16 FP registers). Nothing compared to MMX/SSE/AVX, but relatively complex.
Re: Archiving otrona attache disks
On Tue, 24 Aug 2021, Fred Cisin via cctech wrote: The 96tpi ones are 800K, and should be treated like any other "Quad Density" CP/M disk. Just for my own curiosity, can a "typical" high-density 5.25" drive correctly image a 96tpi disk? Thanks Fred! g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_!
Re: Archiving otrona attache disks
On Tue, 24 Aug 2021, Bill Degnan wrote: Fred, Just for the purpose of imaging the disks, is there any reason I cant treat these disks like any other 5 1/4" cpm 360k disk? Bill Treat them just like any other 5.25" MFM CP/M disk. IIRC, the 48TPI ones are 400K, with 512 bytes per sector, 10 sectors per track. The 96tpi ones are 800K, and should be treated like any other "Quad Density" CP/M disk. They also had a 96tpi MS-DOS format. Same thing, but obviously, with an MS-DOS, rather than CP/M file system. For those who may not remember the Otrona Attache, it was smaller and lighter than the other luggables. They had an advertisement with a Charlie Chaplin look-alike, comparing carrying it VS a 5150 (on a card table) down a broad set of stairs (in front of a capitol building?). IBM had been using the "Little Tramp" in their advertising, and asserted OWNERSHIP of the Charlie Chaplin "Little Tramp" character and image, and made them cease and desist. I can't find an image, nor even a mention, with GOOGLE. -- Grumpy Ol' Fred ci...@xenosoft.com
Re: Archiving otrona attache disks
Fred, Just for the purpose of imaging the disks, is there any reason I cant treat these disks like any other 5 1/4" cpm 360k disk? Bill On Fri, Aug 20, 2021, 9:09 PM Fred Cisin via cctech wrote: > On Fri, 20 Aug 2021, Bill Degnan via cctech wrote: > > Is there a simh for the otrona attache? I have some.disk images created > > with Dunfield's utility..if not I will try to read them by using the > Zorba > > portable, which is pretty good with varied formats. > > Bill > > Otrona is fairly straightforward for format conversion. > CP/M and MS-DOS. There might have been other operating systems for them, > but I didn't run into any. > They had 40 track and 80 track drives. > 512 bytes per sector, so they can be done using Int13h, without even > needing Int1Eh. > 10 sectors per track; inter-sector gaps were tight but not unreasonable. > I don't remember whether they were numbered 0 - 9 or 1 - 10 > >
Re: Extremely CISC instructions
As a followup, I did find the following article about the Saxpy Matrix-1: https://techmonitor.ai/techonology/the_saxpy_affair_and_why_we_all_have_to_worry_about_the_theft_of_its_secrets --Chuck
Re: Extremely CISC instructions
On 8/24/21 10:40 AM, Van Snyder via cctalk wrote: > That's the BLAS SAXPY (or DAXPY) routine, a fundamental step in > Gaussian elimination. Speaking of which, do any specimens of the Saxpy Matrix-1 still exist? Saxpy Computer was a brief flash in the supercomputing universe; fell onto bad times when a former employee was caught selling secrets to the Soviets. Afterward, the company went into bankruptcy, if memory serves, sometime in the 1980s. SAXPY was a program in the LINPACK suite, and well known to FORTRAN benchmarkers. Ref: http://www.netlib.org/lapack/explore-3.1.1-html/saxpy.f.html Since LINPACK could well mean the difference between a sale and a "thanks for trying", it received a lot of attention. --Chuck
Re: Extremely CISC instructions
On Tue, 2021-08-24 at 15:55 +, dwight via cctalk wrote: > DSP processors, like the 2100 series of Analog Devices, one single > instruction that would take value from one array and multiply it by a > value from another array and then add it to another array, while > incrementing the indexes. That's the BLAS SAXPY (or DAXPY) routine, a fundamental step in Gaussian elimination. > I'd say that was CISC like. > Dwight > >
RE: Extremely CISC instructions
Hi Tom, Well for me the VAX has some of the most interesting instructions, so the POLY instruction will evaluate a polynomial and EMOD will multiply and separate the integer and fractional parts. I also find it interesting that some architectures will only allow the privilege state to be examined if you are in supervisor/privileged state which allows software virtualization. The IBM 370 has this feature but the later machines so XA, 390, and the various flavours of "Z" do not. So the 370 hypervisors VM/370 and VM/SP do software virtualization VM/XA, VM/ESA and zVM need to have the "SIE" instruction, Start Interpretive Execution which runs a virtual machine from microcode. A similar feature exists in modern Intel/AMD chips which greatly improve the performance of hypervisors such as VMWARE, HyperV and VirtualBox Dave G4UGM > -Original Message- > From: cctalk On Behalf Of Tom Stepleton > via cctalk > Sent: 24 August 2021 01:39 > To: cctalk@classiccmp.org > Subject: Extremely CISC instructions > > Hello, > > For the sake of illustration to folks who are not necessarily used to thinking > about what computers do at the machine code level, I'm interested in > collecting examples of single instructions for any CPU architecture that are > unusually prolific in one way or another. This request is highly > underconstrained, so I have to rely on peoples' good taste to determine > what counts as "interesting" here. Perhaps a whole lot of different kinds of > work or lots of different resources accessed is what I'm after. I expect these > kinds of "busy" instructions were more common in architectures that are > now less common, so perhaps this list is a good place to ask. > > For example, if we're thinking "number of times an item is retrieved from > RAM", then any application of the x86 string instructions that could walk over > memory for a while perhaps aren't so interesting. By contrast, by my count, > the NS32000 series instruction "addw ext(4), ext(7)" requires at least five > separate noncontiguous retrievals just to fetch the arguments into the ALU. > (Note that I'm not differentiating between different sizes of data here: > loading a 16-bit item and loading a 32-bit address both count as a "retrieval" > in this example.) > > Instructions that are simply lengthy might be interesting, but not always: > long literals or lots of redundant prefixes on x86 aren't that impressive, for > example. > > Number of registers read or modified might be good too, but just saving or > loading for the sake of subroutine calls (e.g. "movem.l r0-r7/a0-a6,-(sp)" > on the 68k) seems pretty pedestrian. > > Other criteria may seem worthwhile; I trust peoples' judgement on this. > Although I don't know it well, I suspect VAX will place well in one way or > another. But to give an example of a candidate instruction that's prolific in > a > way I find more noteworthy, I'll go back to the NS32k and offer > > addw ext(4)+6[r1:w], ext(7)+12[r2:w] > > which in order to get its arguments (I think) requires the five retrievals > already mentioned and adds two shifts and four additions to the bill. I think > this statement reads: "Add the r1'th word counting from 6 bytes past the > fourth address in the current module's link table to the r2'th word counting > from 12 bytes past the seventh address in the current module's link table". > That's a mouthful --- it takes a lot of work to describe what that one line > does! Maybe that's what I'm hoping to share with people. > > I hope this is interesting to discuss, > --Tom
Re: Extremely CISC instructions
On Tue, 24 Aug 2021, Tom Stepleton via cctalk wrote: Hello, For the sake of illustration to folks who are not necessarily used to thinking about what computers do at the machine code level, I'm interested in collecting examples of single instructions for any CPU architecture that are unusually prolific in one way or another. This request is highly underconstrained, so I have to rely on peoples' good taste to determine what counts as "interesting" here. Perhaps a whole lot of different kinds of work or lots of different resources accessed is what I'm after. I expect these kinds of "busy" instructions were more common in architectures that are now less common, so perhaps this list is a good place to ask. Does a virtual machine count? The BCPL compiler outputs code in few formats, one is called CINTCODE - Compact Intermediate Code. This is a bytecode designed to be interpreted by a suitable interpreter running on real hardware - in the way other bytecode systems work. It has a switch instruction. Actually, it has 2 - one is a linear search and one a binary chop. This is the definition of the binary chop one (because linear is too easy) SWB filler n dlab K1 L1 . . . Kn Ln This instruction is used when the range of case constants is too large for SWL to be economical. It performs the jump using a binary chop strategy. The quantities n, dlab, K1 to Kn and L1 to Ln are 16 bit half words aligned on 16 bit boundaries by the option filler byte. This instruction successively tests A with the case constants in the balanced binary tree given in the instruction. The tree is structured in a way similar to that used in heapsort with the children of the node at position i at positions 2i and 2i + 1. References to nodes beyond n are treated as null pointers. Within this tree, Ki is greater than all case constants in the tree rooted at position 2i, and less than those in the tree at 2i + 1. The search starts at position 1 and continues until a matching case constant is found or a null pointer is reached. If A is equal to some Ki then PC is set using the resolving half word Li , otherwise it uses the resolving half word dlab to jump to the default label. See Section 9.1.3 for details on how resolving half words are interpreted. Obviously it needs the compiler to output the right stuff, but there it is and I won't embarass myself with my implementation of it in 65c816 assembly code.. Gordon
Re: Multiprocessor Qbus PDP-11
On Fri, Aug 20, 2021 at 7:55 AM Paul Koning wrote: > > > > On Aug 19, 2021, at 7:39 PM, Charles Dickman via cctalk < > cctalk@classiccmp.org> wrote: > > > > There are indications in the KDJ11-B processor spec on bitsavers that the > > M8190 could be used in a multiprocessor configuration. For example, bit > 10 > > of the Maintenance Register (17 777 750) is labeled "Multiprocessor > Slave" > > and indicates that the bus arbitrator is disabled. > > Interesting. > > > Would it be as simple as connecting to 11/83 qbus together? And adding > the > > proper software. > > I would not think so. The processor is the bus controller, and you can't > have a bus with two controllers. It would be a bit like trying to connect > a pair of PCs with a PCI or PCIe jumper cable. > > To make these configurations work you need a device in between that > arbitrates the actions of the multiple controllers (PCI people call that a > "non-transparent bridge"). > Understood, but the processor spec indicates that it should be possible to turn off the local arbitrator, so the processor at one end would have its arbitrator on and the processor at the other end would have the arbitrator turned off. > paul > >
Re: Extremely CISC instructions
On Tue, Aug 24, 2021 at 11:38:42AM -0400, Paul Koning wrote: > > > > On Aug 24, 2021, at 6:34 AM, Diane Bruce wrote: > > > > On Mon, Aug 23, 2021 at 09:09:55PM -0400, Paul Koning via cctalk wrote: > >> > >> > >>> On Aug 23, 2021, at 8:38 PM, Tom Stepleton via cctalk > >>> wrote: > >>> ... > > faster if one just did them with the 'normal' instruction set. > > Not too surprising given that the instruction worked 4 bits at a time while a > reasonable software implementation goes 8 bits at a time. > > The more general point is one I learned on the Moto 68040. The task was to > write a fast packet forwarding module (for an FDDI -> Ethernet switch, wihch > ended up being the DECswitch 900). When I studied the instruction timings I > realized the "RISC subset" of the 68040 instruction set and addressing modes > runs in one or two cycles per instruction, while all the other cases take a > great deal more. So I wrote it in the RISC subset, and ended up processing > 60k packets per second, in a 25 MHz processor. > Not at all surpised. That was later done formally in the ColdFire processor. They removed all the CISCy instructions replacing them with macros and left the RISCy instruction set. > paul > > > Diane -- d...@freebsd.org d...@db.net http://www.db.net/~db
Re: Extremely CISC instructions
> On Aug 24, 2021, at 11:57 AM, Peter Corlett via cctalk > wrote: > > On Tue, Aug 24, 2021 at 08:47:33AM -0500, John Foust via cctalk wrote: >> At 04:13 AM 8/24/2021, Peter Corlett via cctalk wrote: >>> move.b ([0x12345678, %pc, %d0.w*8], 0x9abcdef0), ([0x87654321, %sp], %a0*4, >>> 0x0fedcba9) >> And which language and compiler case was this aimed at? > > I have no idea and dread to think, although I chose a worst-case example > which doesn't actually make much sense. Might be block structured languages. The Electrologica X8 has a complex addressing mode that was, I think, designed by E.W.Dijkstra, and intended specifically to support the addressing of variables local to outer blocks. There is a term for this, "display" I think. The basic idea is to have a vector of pointers indexed by the static block number (nesting level), pointing to the newest frame among all the invocations of that block. Then a variable reference translates into a reference to that display (using the static block number) along with the frame offset of the particular variable. In the X8, that's handled in a specific addressing mode. For example "M3[12]" means the effective address is the value found in entry 3 of the display table (pointed at by memory location 63), plus 12. paul
Re: Extremely CISC instructions
On Tue, Aug 24, 2021 at 08:47:33AM -0500, John Foust via cctalk wrote: > At 04:13 AM 8/24/2021, Peter Corlett via cctalk wrote: >> move.b ([0x12345678, %pc, %d0.w*8], 0x9abcdef0), ([0x87654321, %sp], %a0*4, >> 0x0fedcba9) > And which language and compiler case was this aimed at? I have no idea and dread to think, although I chose a worst-case example which doesn't actually make much sense. Those scary-looking double-indirections in the instructions are just the result of a generalised EA calculation mode which combines an inner offset (which may be 0), base register, optional shifted index register, optional indirection (before or after indexing), and an outer offset (which may also be 0), to which the MOVE instruction itself adds indirection. Combining a few of these is normal even on RISC machines: PC-plus-offset and SP-plus-offset are used to get constants and stack-based variables. Adding a shifted index is useful for array lookups. If it's an array of pointers, indirection makes sense. And finally, if it's a pointer to a structure and we want something other than the first field, a constant needs adding. So it's easy to see how one can occasionally end up using this addressing mode and enabling much of its functionality. I suspect this addressing mode is used much more often with address-calculating instructions such as LEA than those which operate directly on the address like MOVE. If the 68000 didn't have a split register file, this could also be (mis)used like it is on x86 to do cheap arithmetic and multiplication by 3, 5, and 9. > Wasn't that a primary driver for complex CISC instructions? That if it > happened often enough, it would be faster or smaller as a single > instruction? You can get a lot of simpler m68k instructions in 22 bytes :) >> (Yet Amiga owners used to poke fun at PC owners with their excessively >> complex x86, which has simpler addressing modes.) > I dunno, 68000 seemed like PDP-11 to me, and I often say one of the big > reasons I quit a particular job was the prospect of my role changing to > having to write 80x86 assembler all day. I encountered the 68000 first, and when I eventually saw the PDP-11 instruction coding a few decades later, the lineage seemed obvious.
Re: Extremely CISC instructions
DSP processors, like the 2100 series of Analog Devices, one single instruction that would take value from one array and multiply it by a value from another array and then add it to another array, while incrementing the indexes. I'd say that was CISC like. Dwight
Re: Extremely CISC instructions
> On Aug 24, 2021, at 6:34 AM, Diane Bruce wrote: > > On Mon, Aug 23, 2021 at 09:09:55PM -0400, Paul Koning via cctalk wrote: >> >> >>> On Aug 23, 2021, at 8:38 PM, Tom Stepleton via cctalk >>> wrote: >>> >>> Hello, >>> >>> For the sake of illustration to folks who are not necessarily used to >>> thinking about what computers do at the machine code level, I'm interested >>> in collecting examples of single instructions for any CPU architecture that >>> are unusually prolific in one way or another. >>> ... >>> Although I don't know it well, I suspect VAX will place well in one way or >>> another. >> >> Indeed. Just its addressing modes, with indirection and two separate >> register indexing operations, are hairy enough. Then consider the decimal >> arithmetic instructions that might have up to 6 operands. > > And who can ever forget the built in CRC instruction? > > Amusingly it was demonstrated that many of the CISC instructions were > faster if one just did them with the 'normal' instruction set. Not too surprising given that the instruction worked 4 bits at a time while a reasonable software implementation goes 8 bits at a time. The more general point is one I learned on the Moto 68040. The task was to write a fast packet forwarding module (for an FDDI -> Ethernet switch, wihch ended up being the DECswitch 900). When I studied the instruction timings I realized the "RISC subset" of the 68040 instruction set and addressing modes runs in one or two cycles per instruction, while all the other cases take a great deal more. So I wrote it in the RISC subset, and ended up processing 60k packets per second, in a 25 MHz processor. paul
Re: Extremely CISC instructions
On 8/24/21 3:34 AM, Diane Bruce via cctalk wrote: > Indeed. Just its addressing modes, with indirection and two separate register > indexing operations, are hairy enough. Then consider the decimal arithmetic > instructions that might have up to 6 operands. > > And who can ever forget the built in CRC instruction? > > Amusingly it was demonstrated that many of the CISC instructions were > faster if one just did them with the 'normal' instruction set. Feh, many ARM Cortex MCUs have a hardware CRC generator. Where's the vector dot product instruction or the transpose instruction? How about the search masked masked key? If CPU doesn't have a variable-length decimal divide it isn't really CISC in the grand sense. --Chuck
Re: Extremely CISC instructions
On Mon, Aug 23, 2021 at 09:09:55PM -0400, Paul Koning via cctalk wrote: > > > > On Aug 23, 2021, at 8:38 PM, Tom Stepleton via cctalk > > wrote: > > > > Hello, > > > > For the sake of illustration to folks who are not necessarily used to > > thinking about what computers do at the machine code level, I'm interested > > in collecting examples of single instructions for any CPU architecture that > > are unusually prolific in one way or another. > > ... > > Although I don't know it well, I suspect VAX will place well in one way or > > another. > > Indeed. Just its addressing modes, with indirection and two separate register > indexing operations, are hairy enough. Then consider the decimal arithmetic > instructions that might have up to 6 operands. And who can ever forget the built in CRC instruction? Amusingly it was demonstrated that many of the CISC instructions were faster if one just did them with the 'normal' instruction set. -- d...@freebsd.org d...@db.net http://www.db.net/~db
Re: Extremely CISC instructions
At 04:13 AM 8/24/2021, Peter Corlett via cctalk wrote: >move.b ([0x12345678, %pc, %d0.w*8], 0x9abcdef0), ([0x87654321, %sp], %a0*4, >0x0fedcba9) And which language and compiler case was this aimed at? Wasn't that a primary driver for complex CISC instructions? That if it happened often enough, it would be faster or smaller as a single instruction? >(Yet Amiga owners used to poke fun at PC owners with their excessively >complex x86, which has simpler addressing modes.) I dunno, 68000 seemed like PDP-11 to me, and I often say one of the big reasons I quit a particular job was the prospect of my role changing to having to write 80x86 assembler all day. And yes I quit that job to become an Amiga magazine writer. :-) - John
Re: Extremely CISC instructions
> On Aug 23, 2021, at 8:38 PM, Tom Stepleton via cctalk > wrote: > > Hello, > > For the sake of illustration to folks who are not necessarily used to > thinking about what computers do at the machine code level, I'm interested > in collecting examples of single instructions for any CPU architecture that > are unusually prolific in one way or another. > ... > Although I don't know it well, I suspect VAX will place well in one way or > another. Thinking some more about addressing modes, there are a couple of examples that are, if not extra complex, at least extra unusual. The strangest addressing mode I ever saw is found on the Electrologica X1. It has the familiar indexed addressing mode called "B" mode, which uses the contents of B1 plus the address field of the instruction as the effective address. So far so good. But then there is C mode, which is like B mode except that the computed effective address is written back into the address field of the instruction. It's used very rarely; one example is in the equivalent of "bzero" in the ALGOL compiler run-time code. With this mode, the address field is set to buffer address - n and the B register to n, for a stride of n. You can find a short example here: http://helloworldcollection.de/#Assembler%C2%A0(X1) Its successor, the X8, drops this addressing mode, but it has some interesting quirks as well. There is a stack addressing mode, related to the indexed mode. In stack mode, if the displacement is negative the stack pointer is decremented by one, if positive it is incremented. So push and pop are not two modes, but happen depending on the specified offset. "MC[0]=A" pushes A onto the stack; "A=MC[-1]" pops that value. paul
Re: Extremely CISC instructions
On Tue, Aug 24, 2021 at 01:38:33AM +0100, Tom Stepleton via cctalk wrote: > For the sake of illustration to folks who are not necessarily used to > thinking about what computers do at the machine code level, I'm interested > in collecting examples of single instructions for any CPU architecture > that are unusually prolific in one way or another. [...] The one that immediately comes to mind is the kitchen-sink MOVE in the 68020 which comes in at 22 bytes: 2 for the instruction itself, then two full-size "full extension words" (one each for the source and destination) which themselves are 2 for the flags, and 4 each for the base and outer displacement. So that'd be something like: move.b ([0x12345678, %pc, %d0.w*8], 0x9abcdef0), ([0x87654321, %sp], %a0*4, 0x0fedcba9) Which does something like this: * Compute 0x12345678 + %pc + %d0.w * 8 * Fetch 4 bytes from that address and add 0x9abcdef0 to that. * Fetch a byte from that address. * Compute 0x87654321 + %sp * Fetch 4 bytes from that address and add %a0*4 + 0x0fedcba9 to that. * Store the previously-fetched byte to that address. (Yet Amiga owners used to poke fun at PC owners with their excessively complex x86, which has simpler addressing modes.) Unsurprisingly, when NXP tried to make m68k a bit more RISCy so it could go faster and compete with ARM in the embedded sphere, one of the things which were tossed out were these mad addressing modes, along with any other encoding which took more than 6 bytes.
Re: 3d modelling software
Rob asked > I think I may need to get a small part 3d printed (some plastic board > mounting guide rails from a PDP 11/24 H7140 PSU). What software is best for > a novice? Preferably free! I've found OpenSCAD to be perfect for things like brackets, machine parts and so on. It's no good for figurines and other complex curved objects, perhaps use Blender for those. It also has its quirks and limitations such as being notoriously crappy at fillets, but even passable versions of those can be achieved now (see https://www.thingiverse.com/thing:4932117). I like being able to model solids from first principles, where the model's source is literally just that, a piece of source code. Easy to email or print. And I know that my model is always going to be around and not beholden to the cloud. You can get the program at http://openscad.org/ Being code I think anyone here on cctalk could pick up the gist of it in only one or two clock cycles. Some public models of mine at https://www.thingiverse.com/1944gpw/designs feel free to look at the source which I provide with all my public designs. An STL file is not a source file, but a .scad file is, and is naturally parametric. And only three consecutive keypresses required to generate an STL file ready for slicing: F5 (preview) then F6 (render) and then F7 (save STL). That's fantastically simple. Other free CAD apps I've used include FreeCAD but I found it crashed when trying to import machine-generated DXF files of involute gears with line segments that weren't properly closed. OpenSCAD imported them no problem. Why not give it a try, I'm sure it would be ideal for your guide rails. Steve.
