Bill Gunshannon wrote:
>
> With 3.1 available why would you want to run 2.0? Someone mentioned
> a 4.0. I don't remember there ever being anything after 3.1 (promised,
> but never saw it delivered) Would be fun to look at. But I suspect
> anything beginning with 4 is actually Ultrix-32 which I think went as
> far as 4.5.
That seems likely, because AFAIR Ultrix-11 never got past 3.X.
In any way I would like to point out that Ultrix-11 and Ultrix-32 are
completely different: Ultrix-11 based on V7 (+addons) and Ultrix-32
based on 4.2BSD (+addons).
I actually still have Ultrix-32 3.1 running on a DECstation. It really
is nothing like running Ultrix-11 3.1, which I did many years ago.
Dennis
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
Hi!
I'm offering an Atari Portfolio HPC-004 along with a 64 KB Memory Card
for the cost of shipping (located in Germany.) It boots / works (using
batteries), but I'm missing its original wall wart.
Is anybody interested?
Thanks,
Jan-Benedict
--
I've been working on a new memory board for the Apple ///, using (somewhat)
modern and still-in-production components, especially CMOS static RAM
rather than DRAM. Last night I soldered the connectors, sockets, and
passives of my first prototype:
https://flickr.com/photos/_brouhaha_/albums/72157719738576267
I need to do some testing for shorts, etc. before I attempt to actually use
it in an Apple ///. I expect that some debugging of the design will be
required.
The Apple /// design is _much_ more complex that the Apple II and IIe. I
intended this board to provide 512KiB of RAM, but I've already determined
that some design changes will be required for that, so this prototype will
only support 256KiB.
The early Apple /// design, as documented in US patents, would have
supported up to 512KiB of RAM, but the actual shipped design reduced that
to 256KiB. There was a third-party 512Kib emory board from "On Three",
which required pulling various chips from the motherboard and running
cables from those to the memory board.
The SOS operating system, as shipped, only supported 256KiB. On Three
modified the SOS bootloader to detect and use 512KiB. Some Apple ///
application software also had trouble with 512KiB, and On Three patched
some of those.
>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.
This is perhaps outside even the vague bounds you were thinking of, but it
probably wins the 'unusually prolific' prize by a gigabyte-mile.
Behold, the hidden, secret and heinous X86 2-byte 'launch instruction' 0x0F, 0x3F.
See this talk about the discovery:
https://www.youtube.com/watch?v=jmTwlEh8L7g
DEF CON 26 - Christopher Domas - GOD MODE UNLOCKED Hardware Backdoors in redacted x86 46:03
DEFCON Conference Oct 23, 2018
Complexity is increasing. Trust eroding. In the wake of Spectre and Meltdown, when it seems that things cannot get any darker for processor security, the last light goes out. This talk will demonstrate what everyone has long feared but never proven: there are hardware backdoors in some x86 processors, and they're buried deeper than we ever imagined possible. While this research specifically examines a third-party processor, we use this as a stepping stone to explore the feasibility of more widespread hardware backdoors.
After which you will never trust your Intel-based PC, ever again.
Guy
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.
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. There is also section
6.6, "Cache Multi-Processor Hooks", that describes cache features that
allow multiprocessor operation.
Would it be as simple as connecting to 11/83 qbus together? And adding the
proper software.
Anybody ever heard of such a thing?
Chuck
