A Flight Of Fancy
invalid
did no more than to increase the size of the memory reference
from 7 bits by 20 bits to make it a 32-bit instruction set, but
otherwise made no extensions to the Instruction Set?
2^27 is, subject to typos, 134,217,728.
This would of course be a word count, giving an effective memory size
of 1/2 GigaByte (4 bytes per 32 bit word; 2^29 = 536,870,912)
No need to move out of page Zero.
No need of Instruction Fields and Data Fields.
Byte Swap becomes meaningless unless it swaps 16 bit portions, making
it compatible with UniCode characters, but then that would be a change
to the Instruction Set.
rk
> What might be obtained with the PDP8-E instruction set if we
> did no more than to increase the size of the memory reference
> from 7 bits by 20 bits to make it a 32-bit instruction set, but
> otherwise made no extensions to the Instruction Set?
Wouldn't it be more "natural" to increase it to 24 bits?
Thus, we'd go from a page size of 7 bits (12-5) to 19 bits (24-5)
which is 1/2 MW, which may still be considered "enough", certainly
2^24=16MW should be enough for most programs... :-)
> 2^27 is, subject to typos, 134,217,728.
>
> This would of course be a word count, giving an effective memory size
> of 1/2 GigaByte (4 bytes per 32 bit word; 2^29 = 536,870,912)
>
> No need to move out of page Zero.
Page 0 at 1/2MW (or even your 128MW) would certainly be big enough...
> No need of Instruction Fields and Data Fields.
>
> Byte Swap becomes meaningless unless it swaps 16 bit portions, making
> it compatible with UniCode characters, but then that would be a change
> to the Instruction Set.
You now have far more bits to play with in the 07xxxxxxx operate
microinstructions space :-) It would be a shame to not use those...
Cheers,
-RK
vrs42
> What might be obtained with the PDP8-E instruction set if we
> did no more than to increase the size of the memory reference
> from 7 bits by 20 bits to make it a 32-bit instruction set, but
> otherwise made no extensions to the Instruction Set?
>
> 2^27 is, subject to typos, 134,217,728.
>
> This would of course be a word count, giving an effective memory size
> of 1/2 GigaByte (4 bytes per 32 bit word; 2^29 = 536,870,912)
>
> No need to move out of page Zero.
>
> No need of Instruction Fields and Data Fields.
I disagree, somewhat. I think lots of folks have data intensive
applications that
need more than 1/2 Gb. So I'd leave the paging in, and have the base
machine
be 4Gw. Fields would be an expansion option, as before :-).
> Byte Swap becomes meaningless unless it swaps 16 bit portions, making
> it compatible with UniCode characters, but then that would be a change
> to the Instruction Set.
One of the things we'd have to decide is what to do with the 20 extra
bits in IOT
and OPR instructions. I can see just having a boatload of possible I/
O device
addressing (and maybe a couple more function bits) for IOT. But OPR
would
have all kinds of room for stuff.
I'd say leave BSW alone, but define a new pile of shifts and swaps
using
(some of) the extra instruction bits, which would do various byte
reordering
(with various sizes of byte).
Of course, you *still* can't get a proper C compiler unless you
address the
lack of a stack and addressing for non-static storage. Similarly for
other
modern languages where recursive functions are the default.
There are also performance issues with the single register,
necessitating
lots of round trips over the memory bus, etc. Those are not really
fixable
without losing the resemblance to a PDP-8, though.
Vince
invalid
news:d3a507d6-aec7-4b1e...@a39g2000pre.googlegroups.com...
>
> Of course, you *still* can't get a proper C compiler unless you
> address the
> lack of a stack and addressing for non-static storage. Similarly for
> other
> modern languages where recursive functions are the default.
>
There was a dodge used by the RCA COSMAC 1802 whereby you
had a subroutine-to-call-other-subroutines which I'd employ here. It would
implement a stack, and was a feasible method of working even with the
original PDP8. Actually, I'm skimming through my (virtually unused)
copy of "Introduction To Programming" to see if it was ever suggested thus.
Your in-line subroutine call would be followed by the address of
the subroutine that you really wanted to call. Using one of the
auto-incrementing
locations on page 0, say 10, for your stack pointer, your return-from
subroutine
would be simply JMS I 10.
Unfortunately, doodling a bit of code to do this, there's rather too much
farting
around for my liking, caused by the pre-increment, ie, in order to do the
stacking,
you first have to subtract 2 from the pointer 10, in order to arrive at the
next location
on the stack, then you have to subtract one from it in order to leave it in
the
right position for the return-from-subroutine operation.
Anyway. it's all a flight of fancy!
invalid
news:aeecadcf-d507-4fc4...@d21g2000yqn.googlegroups.com...
On Nov 19, 5:01 am, "invalid" <inva...@invalid.invalid> wrote:
>> What might be obtained with the PDP8-E instruction set if we
>> did no more than to increase the size of the memory reference
>> from 7 bits by 20 bits to make it a 32-bit instruction set, but
>> otherwise made no extensions to the Instruction Set?
> microinstructions space :-) It would be a shame to not use those...
"vrs42" <v.sly...@verizon.net> wrote in message
news:d3a507d6-aec7-4b1e...@a39g2000pre.googlegroups.com...
> invalid wrote:
>> What might be obtained with the PDP8-E instruction set if we
>> did no more than to increase the size of the memory reference
>> from 7 bits by 20 bits to make it a 32-bit instruction set, but
>> otherwise made no extensions to the Instruction Set?
>
> One of the things we'd have to decide is what to do with the 20 extra
> bits in IOT
> and OPR instructions. I can see just having a boatload of possible I/
> O device
> addressing (and maybe a couple more function bits) for IOT. But OPR
> would
> have all kinds of room for stuff.
> I'd say leave BSW alone, but define a new pile of shifts and swaps
> using
> (some of) the extra instruction bits, which would do various byte
> reordering
> (with various sizes of byte).
>
Taking these poits from "rk" and "vrs42" together, part of my dreaming was
to implement such a thing by simulation. By sticking to the original
Instruction Set,
there are only 4096 possibilities, which could be implemented with
a (rather large) switch statement in C.
For example, rather than having code to separate out the memory portion from
the instruction portion, a large switch statement, (with one case for each
of the 128
possibilities on memory reference instructions (or 512 if you also include
Page 0
and indirect options)) could be generated by a C macro.
There's no shortage of program storage in modern PCs!
I had this in mind as a training exercise to get me moving in C#.Should be
possible to
create a reasonable representation of a PDP8 front panel in that language,
even if it
means having a switch register of 32 buttons.
vrs42
> "vrs42" <v.sly...@verizon.net> wrote in message
> news:d3a507d6-aec7-4b1e...@a39g2000pre.googlegroups.com...
> >
> > Of course, you *still* can't get a proper C compiler unless you
> > address the
> > lack of a stack and addressing for non-static storage. Similarly for
> > other
> > modern languages where recursive functions are the default.
>
> There was a dodge used by the RCA COSMAC 1802 whereby you
> had a subroutine-to-call-other-subroutines which I'd employ here. It would
> implement a stack, and was a feasible method of working even with the
> original PDP8. Actually, I'm skimming through my (virtually unused)
> copy of "Introduction To Programming" to see if it was ever suggested thus.
I'm familiar with it. It is used in a bunch of PDP-8 software,
including the various
FOCAL interpreters.
That gives you a limited recursion, but doesn't solve the problem of
addressing
non-trivial amounts of storage that isn't of static storage class.
What's needed
there is something like a "frame pointer", referencing into a stack
(or heap), and
some way to reference off of it without spending dozens of
instructions on address
arithmetic.
We should start a different thread if we want to talk much about the
difficulties of
implementing these language features though, as they have nothing
really to do
with your idea of a PDP-8 that's 1024*1024X bigger than the original.
Vince
invalid
> invalid wrote:
>> "vrs42" <v.sly...@verizon.net> wrote in message
>> news:d3a507d6-aec7-4b1e...@a39g2000pre.googlegroups.com...
>> >
>> > Of course, you *still* can't get a proper C compiler unless you
>> > address the
>> > lack of a stack and addressing for non-static storage. Similarly for
>> > other
>> > modern languages where recursive functions are the default.
>>
>> There was a dodge used by the RCA COSMAC 1802 whereby you
>> had a subroutine-to-call-other-subroutines which I'd employ here. It
>> would
>> implement a stack, and was a feasible method of working even with the
>> original PDP8. Actually, I'm skimming through my (virtually unused)
>> copy of "Introduction To Programming" to see if it was ever suggested
>> thus.
>
> I'm familiar with it. It is used in a bunch of PDP-8 software,
> including the various
> FOCAL interpreters.
In "Introduction To Programming" the technique is suggested, not
as a way of calling subroutines, but for implementing interruptable
interrupt routines, and saves the Accumulator, Link and PC.
OK, as you say, enough of this thread!