Backup of
https://joelrees-novels.blogspot.com/2020/08/33209-rocks-2805.html.
Chapter 13.8 Straits -- Intellectual Property Agreements
Chapter 14.0: Rocks -- 2805
[202008262244 -- 2nd edit, with register maps:]
Bill grinned sardonically. "Well, I think this will work out well."
(You may want to put your BS meter away for this chapter, or at least set the threshold level pretty high.)
Bob
chuckled. "Stephanie, can you get together with Carrie and see that
what these three signed gets replaced with a more appropriate
agreement?"
"I'd be happy to, sir."
"The same as Joe and Julia's agreements, with an addendum for their projects?" Ms. Philips asked.
Bill answered for him. "Yes, yes, of course."
And Bob nodded.
Ms. Steward, Ms. Philips, Mike, our Bob, and Jennifer got together at one end of the table.
As
Julia and I connected her mainboard to one of the TVs, I whispered to
her. "I thought the two guys were from Motorola's legal department."
"I did, too," she whispered back. "Must be much higher up in management."
I nodded my agreement.
(No, I never even came close to meeting Motorola's Bob and Bill in the real world.)
A number of engineers came in, bringing in pizza and liquid refreshment.
"Your
friends," Motorola's Bob said to me with a grin, "are having pizza
elsewhere. I think we should have some pizza in here, too." He turned to
one of the engineers. "Jeff, I hope there's something non-alcoholic to
drink?"
The engineer named Jeff started, and looked up guiltily from the six-packs he was carrying. "Erm ...."
An
engineer on the other side of the room called out, "Denny made sure we
had root beer, and I made sure we had some other options." He held up
two-liter bottles of soft drinks. "Not all of us are fueled by beer."
"Good job, Tobe."
Tobias gave Bob a thumbs-up.
As we ate pizza and talked, we demonstrated what we had done so far -- the ROM
menus, BASIC, TSC's debug system, and Flex, and using Flex to run Motorola's
assemblers.
We shared some comments and discussion of the process of getting Flex to run on the Micro Chroma 68, and I
described my dynamic RAM refresh circuit, explaining how I borrowed the video
scan counter of the 6847, and mentioning the problems I had run into with my original design. I also explained the simplistic
bank switching that made it possible to run Flex.
Several of the engineers commented on how my refresh circuit sounded similar
to a circuit the engineers who worked with Radio Shack on the Color Computer had produced before
they designed the sequential address multiplexor as a separate circuit. Not yet being familiar with the SAM, I couldn't comment.
Jennifer,
our Bob, and Mike had taken care of their paperwork by then. Bob knew
something about the SAM already, and he discussed it a bit with the
engineers.
We showed them the 6801
daughterboard on Julia's mainboard, and her keyboard, and she described
the way we were using the 6805 and its timer to scan and debounce the
keyboard and control the hexadecimal display, augmenting the I/O with
either latch or multiplexor.
Then she loaded Forth on her computer from
tape and used it to send numbers out to her keyboard's hexadecimal
display.
We stopped for a few minutes while Bob, Bill,
and some of the managing engineers discussed whether Motorola wanted to
ask us for permission to use the keyboard decoder/numeric display design
and code for an application note, and the upshot was that they did, and
the five of us agreed to discuss that with the rest of the group.
Most
of the engineers were appreciative of Julia's Forth examples, and I
explained what I had done to get the drivers to work, mentioning that we
hadn't solved the disk problems yet for Forth.
My disk
interface was the topic of considerable discussion, and Ms. Philips and
Ms. Steward quickly produced a sharing addendum to allow us to get the
schematics out for everyone to look at. Before long, Julia and I had an
addendum to our agreement, an internship contract for producing several
tech notes on the use of the 6801 as a floppy disk controller. The
addendum allowed Motorola the option of building a semi-custom "system
on a chip" SOC floppy disk controller based on my circuits.
Denny
had already shared the schematics Julia had drawn up from my scrawls
with some of his friends. But now the context was Motorola, so the
addendum was deemed wise.
"Ah, to be an undergrad with
all the time in the world again," Tobias reflected jocularly. "Do you
think you could get a 6805 to handle the floppy controller functions?"
I
tilted my head and thought. "That would probably limit sector size,
with X being only eight bits. Come to think of it, the size of X might
require enough extra code to prevent the processor from keeping up with
the data."
Another engineer, Sharon, asked, "What's your general impression of the 6805?"
"It does the job for little things like the keyboard controller," our Bob volunteered.
I concurred.
There was general approval of that analysis.
"But I miss stack support," I added.
"On an eight-bitter?" Jeff queried. "You'd prefer the 6502, maybe?"
Jennifer noted, "The 6502 is a clever design, but it belongs to MOS Technologies and Commodore, doesn't it?"
(In
the real world, Motorola might have been smart to use their patent
agreements with MOS Technologies and second-source the 6502 in the late
1970s. They did offer to produce SOC chips with the 6502 as the CPU core
in the mid-to-late 1980s. But that idea is not for this story.)
"The
6502 is a good chip," I asserted. "It straddles some boundaries like
the 6809, but I think the way it does so constrains compatible upgrade
paths." I paused for thought and emphasis. "Every application wants room
to grow. Maybe some shouldn't, but many can profitably grow in scope
and function. And growing software reliably wants things like code
re-use by re-entrant subroutine call, and keeping subroutines re-entrant
requires something like a stack that you can push to and pop from, for
parameters and local variables. There's no push or pop on the 6805."
Julia
added, "Even if you aren't calling subroutines a lot, a stack helps
manage RAM. Global RAM is harder to keep track of, even if you never
re-use any variables."
I turned and raised my eyebrows. "You're picking this stuff up."
"A little. Dad has been explaining things you haven't."
"Oh. Sorry. I'll have to do better."
"It's okay." She smiled. "He enjoys it. He always wanted his oldest child to be an engineer."
"Now I know why he likes me so much."
We grinned at each other, then Julia coughed discreetly.
I
ducked my head and turned back to the engineers, several of whom were
quietly clapping their hands, rolling their eyes, or pretending to give
us wolf-whistles.
"Anyway, as Julia points out, a stack
you can reference makes RAM much easier to manage. Of course, you can
synthesize a stack, but synthesizing is slow, and a disincentive, and
the code to support the synthesized stack is a distraction."
An engineer named Pete objected. "Moving up to the 6801 is not that hard."
"But
it does require reworking a lot of the code, and checking all of it for
side-effects of the differences between the two," I parried. "And there
are the bit manipulation instructions in the 6805 that the 6801 does
not have, easy enough to synthesize on the 6801, but still requiring
time and effort. Adding stack support to the 6805 ought not to be that
much of a change, and it would support quite a bit of application
growth. That would give the customers' engineers much more confidence in
choosing the improved 6805 for small projects with the potential to
become large."
(The 68HC11, an evolutionary step from
the 6801 that Motorola introduced in 1984, did have bit manipulation
instructions. And the 6805 itself later evolved to the confusingly named
68HC08, which did introduce more complete stack support via instruction
pre-byte escape -- single stack with stack indexing, as opposed to the
dual stack and index marking I suggest below. In the real world.
Several years later.)
Jeff countered, "Okay, how do
you propose to add stack support with minimal change? Pre-bytes like on
the 6809 are too expensive for a pure eight-bitter."
(Well, they were too expensive in the early 1980s.)
"Add
a second stack register. Maybe call it U for user stack, following the
6809's register naming. Add push and pop instructions that push and pop
to the U stack, and transfer instructions that allow moving U to X and
back. And instructions to save U and restore it using the S stack. Eight
instructions should do the trick."
Julia handed me a sheet of scratch paper, and I wrote down the additional instructions:
PSHUA, PULUA
PSHUX, PULUX
PSHSU, PULSU
TUX, TXU
I drew out a map of the registers of the 6805, except for the condition codes:
| 6805 register |
b15 | b14 | b13 | b12 |
b11 | b10 | b9 | b8 |
b7 | b6 | b5 | b4 |
b3 | b2 | b1 | b0 |
| A: |
|
A7 | A6 | A5 | A4 |
A3 | A2 | A1 | A0 |
| X: |
|
X7 | X6 | X5 | X4 |
X3 | X2 | X1 | X0 |
| SP: | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
1 | (SP6) | SP5 | SP4 |
SP3 | SP2 | SP1 | SP0 |
| PC: |
-- | -- | -- | PC12 |
PC11 | PC10 | PC9 | PC8 |
PC7 | PC6 | PC5 | PC4 |
PC3 | PC2 | PC1 | PC0 |
Then I drew out a modified map, including the U stack:
| 2805 register |
b15 | b14 | b13 | b12 |
b11 | b10 | b9 | b8 |
b7 | b6 | b5 | b4 |
b3 | b2 | b1 | b0 |
| A: |
|
A7 | A6 | A5 | A4 |
A3 | A2 | A1 | A0 |
| X: |
|
X7 | X6 | X5 | X4 |
X3 | X2 | X1 | X0 |
| U: | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
1 | (U6) | U5 | U4 |
U3 | U2 | U1 | U0 |
| SP: | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
0 | 0 | SP5 | SP4 |
SP3 | SP2 | SP1 | SP0 |
| PC: |
-- | -- | -- | PC12 |
PC11 | PC10 | PC9 | PC8 |
PC7 | PC6 | PC5 | PC4 |
PC3 | PC2 | PC1 | PC0 |
"Keeping the stacks separate will allow
moving the return stack out of the direct page. It could also be given
its own port to the CPU, in its own address space, with separate address
and data lines. That would allow proceeding to the next instruction
while the call instruction stacks the return address. That way, calls
should end up costing no more than jumps, and it should be possible to
make the return operator faster, as well."
The comment about calls taking less time got some attention and discussion.
"Subroutines," I continued, could look like this:
ROUTINEA
TUX
LDA 0,X ; 1st parameter
LDX 1,X ; 2nd parameter
...
TUX
LDA 2,X ; 3rd parameter
...
INX ; clear all parameters
INX
INX
TXU
RTS
"But X is only eight bits," an engineer named Wayne objected.
"S
is only six or seven bits in the 6805. The return stack is so small it
that it will run out of memory before it cycles through the addresses
allocated to it in the direct page. But you can move it out of the
direct page and no one would notice, and it could still be effectively
less than eight bits to be decremented and incremented by the push and
pop.
"If it weren't for wanting to sometimes directly
shift local variables, and the lack of sixteen-bit index offsets for the
unary instructions in the 6805, you could put the parameter stack
outside the direct page, too. Putting it where the return stack is now
should be no problem, at any rate, and allow access by unary
instructions."
Several of the engineers started scribbling on scratch paper.
Sharon said, "This could be useful."
An engineer named Chuck intoned, "Room in the design for improvement is good engineering."
Bill asked, "Are you taking notes on this, Julia?"
"Is that okay?"
"Can we get a copy, and can we mark parts we don't want shared outside?"
"Sure."
"In that case, thank you, make sure you get that bit about room for improvement in, and please continue."
He and Motorola's Bob again exchanged silent words, and both nodded in agreement.
I shook my head and said quietly, "I presume upon you too much."
Julia grinned. "I'll claim my pay when we get back home."
I grinned back.
"Get a room!" There was a bit of chuckling. We had an audience again.
An engineer named Jack objected. "Isn't dedicating RAM to a second stack a waste?"
I
shook my head. "RAM is easy to make and relatively easy to test, isn't
it? Shouldn't it be cheap? Like candy. And the call stack doesn't have
to be completely inaccessible. If it's in the extended address space, it
would be accessible via extended addressing or 16-bit index offsets."
An
engineer named Monty grumbled to himself. "Testing RAM is a good way to
bring up new processes, too. Forcing the customer to scrimp on RAM is
just a little anti-social."
Motorola's Bob chuckled at that, and asked Julia to quote Monty on it.
Jeff
was also sketching something on note paper. "Separate address spaces.
We could put part of the direct page RAM in its own address space and
give it its own port to the ALU, and shave a cycle of access time for
that area in direct page RAM," he muttered, half to himself.
Julia repeated, sub-vocalizing, "... shave a cycle for the direct page RAM."
Jennifer overheard Jeff, and asked him, "Could that be done without making it difficult to speed the processor up?"
Jeff scratched his head. "Actually, if we're careful, it should make it easier to keep things in sync in a process shrink."
"I was thinking about overclocking."
Jeff
chuckled. "Overclocking is one of those dirty secrets we don't talk
about, but it can be used to predict whether certain aspects of a
process shrink will work."
Our Bob joined him in chuckling.
"Is a process shrink where you make the masks smaller?" Jennifer asked.
Our Bob nodded.
Jeff answered, "It's more than that, but, yeah."
"Could that be used to improve access time to the parameter stack?" I asked.
"That would be a bit more complicated," he replied. "Might be too much beyond the concept of an eight-bit micro-controller."
"You
know," I commented, "one thing I'd like to have is a way for the CPU to
catch the condition when calls or interrupts try to push too much on
the stack, and when return instructions try to pull too much off."
"How can you save state on the stack when the stack isn't valid?" Wayne asked in a tone that was almost rhetorical.
"Could
you have a limit register for S that could trigger an interrupt when a
call or interrupt would decrement S below it? The limit register could
be set by the program, high enough to allow the stack interrupt room to
save state without walking on variables."
Jeff looked
up from his scratch calculations. "Shadow register sets that get
switched in when handling interrupts could be a rather elegant solution
to the stack overflow conundrum."
Julia held her hand up. "Can you help me write that as a note?"
"Interrupts
work like calls on our processors. They save the processor state on the
call stack. That allows interrupts to nest, to a certain extent. A
stack overflow interrupt would fundamentally be unable to nest, so
saving state somewhere else might make sense. Some processors have
shadow registers --"
Our Bob cleared his throat and
said, in a loud whisper, "Z-80. And the 68000's A7 system stack,
although that's just one register."
"-- for fast
context switches. Shadow registers might be one place where you could
save the processor's state on stack overflow."
Julia and Ms. Philips conferred with Jeff and our Bob on this and Julia continued with her notes.
"Speaking
of the interrupt stack," an engineer named Greg pointed out, "stacking
the U stack on interrupts will mess with stack frame compatibility."
"That's part of the reason I call this ideal processor with conflicting specifications the 2805," I explained.
"Conflicting specifications," Motorola's Bob chuckled, and all the engineers joined him.
"Giving
the processor another name would help let customers know not to expect
perfect compatibility," Wayne nodded. "But it also might make sense not
to automatically save the U stack pointer." He frowned in thought.
"So, while we're critiquing the 6805, is there anything else?" Motorola's Bob asked.
"Not
enough I/O pins. We had to use either an external 8 bit latch or an
external multiplexor to get enough I/O bits to read 64 keys. If we had a
package with sixteen more bits of I/O, we could decode larger keyboards
without external parts and still give a parallel interface to the main
processor. A serial keyboard interface could be done with fewer, but it
would still need more than we have."
Julia looked up as
she handed Ms. Steward another page-full of notes. "Serial keyboard
cables will be better for office computers anyway, right, Joe?"
I agreed.
Jeff
nodded. "Flatpack can give 64 pins in a reasonably small package.
Socketing those is expensive for now, but surface mount is cheap."
Julia
stopped him for explanation, and he drew pictures for her. "Flat-pick
looks more like a square black chip than a millipede. Contacts on the
edges like this. Sockets for them look like cups, but they are often
soldered flat on the circuit board."
"So separate parts might actually be a better engineering option?" I asked.
"Maybe."
"Anything else?" Motorola's Bob prompted.
"Daydreaming time?" I laughed.
"Sure." He grinned.
"The
6801's eight-bit multiply is useful. A pair of eight-bit divides --
integer and fractional -- might be useful, too. But I'm thinking about a
complete one-bit multiply and one-bit divide."
He furrowed his brow. "Single bit? That seems like swimming against the current."
"Software
multiplies spend a lot of time in branch instructions. If you could do a
full single-bit multiply with one instruction and stack those
instructions up, you could cut the time for a multiply to maybe a
quarter of the time of a software multiply on the 6805 and 6801, without
the complexity of a full multiplier circuit. You could get similar
improvements with a single-bit divide."
(Again, many
versions of the 6805 ended up getting a full 8-bit multiplier circuit,
and the 68HC11 ended up getting both the 8-bit integer and fractional
divides, in the real world.)
Greg responded. "Which
algorithm, and how are the arguments addressed? Several known pits to
fall into, but it might be worth looking at again."
Bill had picked up the Forth listing, and was looking at the first page.
"This is the license for using Forth?" he asked.
"For the Forth Interest Group's model interpreter," I replied
Monty
explained, "There are many Forth development systems with more
traditional licensing. The Forth Interest Group uses the liberal license
and some of the models are known to be a little buggy in places. In
some cases, it's almost as if they just threw code over the wall and
abandoned it."
"How do you mean?" Bob asked.
"A
liberal license requires an active development team to be useful. The
development team can charge to fix bugs. But their model for our 6800
has nobody following up on it."
Bill laughed. "There's something cynical about that."
Monty
shrugged. "On the other hand, the user is also able to look for and fix
bugs. I saw this work at MIT. The group that works with the liberally
licensed LISP interpreters only allows contributions that are liberally
licensed into their code base. It's a rather elegant approach to
sharing. Code that doesn't get used doesn't get fixed."
Bill's forehead wrinkled. "Elegant and efficient. Survival of the fittest. Hmm."
(I
should note, I was actually as prescient as the me of this novel -- two or three years
later in my college career in the real world.
And we should also assure ourselves that the real engineers
who worked for the real Motorola were aware of pretty much all of this.
Which
path is best is often not clear. Motorola's management in the real
world made decisions that, in hindsight, appear to have been
counterproductive. Examining certain of those decisions is part of my
reason for writing this story.
Hindsight does appear to be clearer than foresight, which is precisely the
reason that this story is something of a waste of time, in effect, an idolatry of idealized abstract mathematical machines.
But
I think
it's less a waste of time than body pornography -- that's essentially an
idolatry of idealized bodies. Modern pornography adds saccharin
personality to the mix. Ideal, not real, imaginary value only.
Speaking
of the real world, of course you know that, in the real world,
Motorola's management and engineers had no reason to do blue-sky
brainstorming like this with me, much less believe my ideas. But for
this experiment to work, in the world of this novel, they must.)
[202008262244 -- 2nd edit, with register maps.]
[202008242104 -- original edit:]
Bill grinned sardonically. "Well, I think this will work well."
(You may want to put your BS meter away for this chapter.)
Bob
chuckled. "Stephanie, can you get together with Carrie and see that
what these three signed gets replaced with a more appropriate
agreement?"
"I'd be happy to, sir."
"The same as Joe and Julia's agreements, with an addendum for their projects?" Ms. Philips asked.
Bill answered for him. "Yes, yes, of course."
And Bob nodded.
Ms. Steward, Ms. Philips, Mike, Bob, and Jennifer got together at one end of the table.
As
Julia and I connected her mainboard to one of the TVs, I whispered to
her. "I thought the two guys were from Motorola's legal department."
"I did, too," she whispered back. "Must be much higher up in management."
I nodded my agreement.
(No, I never even came close to meeting Bob and Bill in the real world.)
A number of engineers came in, bringing in pizza and liquid refreshment.
"Your
friends," Bob said to me with a grin, "are having pizza elsewhere. I
think we should have some pizza in here, too." He turned to one of the
engineers. "Jeff, I hope there's something non-alcoholic to drink?"
Jeff started and looked up guiltily from the six-packs he was carrying. "Erm ...."
An
engineer on the other side of the room called out, "Denny made sure we
had root beer, and I made sure we had some other options." He held up
two-liter bottles of soft drinks. "Not all of us are fueled by beer."
As we ate pizza and talked, we demonstrated what we had done so far -- the ROM
menus, BASIC, TSC's debug system, and Flex, and using Flex to run Motorola's
assemblers.
We shared some comments and discussion of the process of getting Flex to run on the Micro Chroma 68, and I
described my dynamic RAM refresh circuit, explaining how I borrowed the video
scan counter of the 6847, and mentioning the problems I had run into with my original design. I also explained the simplistic
bank switching that made it possible to run Flex.
Several of the engineers commented on how my refresh circuit sounded similar
to a circuit the engineers who worked with Radio Shack on the Color Computer had produced before
they designed the sequential address multiplexor as a separate circuit. Not yet being familiar with the SAM, I couldn't comment.
Bob,
Jennifer, and Mike had taken care of their paperwork by then. Bob knew
something about the SAM already, and he asked the engineers some
questions about it.
We showed them the 6801
daughterboard on Julia's mainboard, and her keyboard, and she described
the how we were using the 6805 and its timer to scan and debounce the
keyboard and control the hexadecimal display, augmenting the I/O with
either latch or multiplexor.
Then she loaded Forth on her computer from
tape and used it to send numbers out to her keyboard's hexadecimal
display.
We stopped for a few minutes while Bob, Bill,
and some of the managing engineers discussed whether Motorola wanted to
ask us for the keyboard decoder code and design for an application note,
and the upshot was that they did, and we agreed to discuss that with
the rest of the group.
Most of the engineers were
appreciative of the Forth examples, and I explained what I had done to
get the drivers to work, mentioning that we hadn't solved the disk
problems yet for Forth.
My disk interface was the topic
of considerable discussion, and Ms. Philips and Ms. Steward quickly
produced a sharing addendum to allow us to get the schematics out for
everyone to look at. Before long, Julia and I had an addendum to our
agreement, a contract for producing several tech notes on the use of the
6801 as a floppy disk controller. The addendum allowed Motorola the
option of building a semi-custom "system on a chip" SOC floppy disk
controller based on my circuits.
Denny had already
shared the schematics Julia had drawn up from my scrawls with some of
his friends, but the context was now Motorola, so the addendum was
deemed wise.
"Ah, to be an undergrad with all the time
in the world again. Do you think you could get a 6805 to handle that?"
an engineer named Tobias asked.
I tilted my head and
thought. "That would probably limit sector size, with X being only eight
bits. Come to think of it, the size of X might require enough extra
code to prevent the processor from keeping up with the data."
Another engineer, named Sharon, asked, "What's your general impression of the 6805?"
"It does the job for little things like the keyboard controller," Bob volunteered.
I concurred.
There was general approval of that analysis.
"But I miss stack support," I added.
"On an eight-bitter?" Jeff queried. "You'd prefer the 6502, maybe?"
Jennifer noted, "The 6502 is a clever design, but it belongs to MOS Technologies and Commodore."
(In
the real world, Motorola might have been smart to use their patent
agreements with MOS Technologies and second-source the 6502 in the late
1970s. They did offer to produce SOC chips with the 6502 as the CPU core
in the mid-to-late 1980s. But that idea is not for this story.)
"The
6502 is a good chip. It straddles some boundaries like the 6809, but
the way it does so constrains compatible upgrade paths," I asserted.
"Every
application wants room to grow," I continued. "Maybe some shouldn't,
but some should, and growth wants things like code re-use by subroutine
call, and keeping subroutines re-entrant requires something like a stack
that you can push to and pop from, for parameters and local variables.
There's no push or pop on the 6805."
Julia added, "Even
if you aren't calling subroutines a lot, a stack helps manage RAM.
Global RAM is harder to keep track of, even if you never re-use any
variables."
I turned and raised my eyebrows. "You're picking this stuff up."
"A little. Dad has been explaining things you haven't."
"Oh. Sorry. I'll have to do better."
"It's okay." She smiled. "He enjoys it. He always wanted his oldest child to be an engineer."
"Now I know why he likes me so much."
We grinned at each other, then Julia coughed discreetly.
I
ducked my head and turned back to the engineers, several of whom were
quietly clapping their hands, rolling their eyes, or pretending to give
us wolf-whistles.
"Anyway, as Julia points out, a stack
you can reference makes RAM much easier to manage. Of course, you can
synthesize a stack, but synthesizing is slow, and a disincentive, and
the code to support the synthesized stack is a distraction."
An engineer named Pete objected. "Moving up to the 6801 is not that hard."
"But
it does require reworking a lot of the code, and checking all of it.
And there are the bit instructions in the 6805 that the 6801 does not
have," I parried. "Adding stack support to the 6805 ought not to be that
much of a change, and it would support quite a bit of project growth.
That would give the customers' engineers much more confidence in
choosing the 6805 for small projects with the potential to become
large."
(The 68HC11, an evolutionary step from the 6801
that Motorola introduced in 1984, did have bit instructions. And the
6805 itself later evolved to the confusingly named 68HC08, which did
introduce more complete stack support -- single stack with stack
indexing via pre-byte, as opposed to the ideas I present below. In the
real world. Years later.)
Jeff countered, "Okay, how
do you propose to add stack support with minimal change? Prebytes like
on the 6809 are too expensive."
(Well, they were too expensive in the early 1980s.)
"Add
a second stack register, maybe call it U for user stack, following the
6809's register naming. Add push and pop instructions that push and pop
to the U stack, and transfer instructions that allow moving U to X and
back. And instructions to save U and restore it using the S stack. Eight
instructions should do the trick."
Julia handed me a sheet of scratch paper, and I wrote down the additional instructions:
PSHUA, PULUA
PSHUX, PULUX
PSHSU, PULSU
TUX, TXU
"Keeping
the stacks separate will allow moving the return stack out of the
direct page. It could also be given its own port to the CPU, its own
address space, with separate address and data lines. That would allow
proceeding to the next instruction while the call stacks the return
address. It should cost no more than jumps, and it should enable faster
returns."
The comment about calls taking less time got some attention and discussion.
"Subroutines," I continued, could look like this:
ROUTINEA
TUX
LDA 0,X ; 1st parameter
LDX 1,X ; 2nd parameter
...
TUX
LDA 2,X ; 3rd parameter
...
INX ; clear all parameters
INX
INX
TXU
RTS
"But X is only eight bits," an engineer named Wayne objected.
"S
is only eight bits in the 6805. The return stack is so small it that it
will run out of memory before it cycles through the addresses in the
direct page. But you can move it out of the direct page and no one would
notice, and it would still be effectively less than eight bits that
would change.
"If it weren't for wanting to sometimes
directly shift local variables, and the lack of sixteen-bit index
offsets for the unary instructions in the 6805, you could put the
parameter stack outside the direct page, too. Putting it where the
return stack is now should be no problem, at any rate, and allow access
by unary instructions."
Several of the engineers started scribbling code out on scratch paper.
Sharon said, "This could be useful."
An engineer named Chuck intoned, "Room in the design for improvement is good engineering."
Bob asked, "Are you taking notes on this, Julia?"
"Is that okay?"
"Can we get a copy, and can we mark parts we don't want shared outside?"
"Sure."
"In that case, thank you, and please continue."
I shook my head and said quietly, "I presume upon you too much."
She grinned. "I'll claim my pay when we get back home."
I grinned back.
"Get a room!" There was a bit of chuckling. We had an audience again.
An engineer named Jack objected. "Isn't dedicating RAM to a second stack a waste?"
I
shook my head. "RAM is easy to make and relatively easy to test, isn't
it? Shouldn't it be cheap? Like candy. But it doesn't have to be
completely inaccessible. It might be accessible via extended addressing
or 16-bit index offsets."
An engineer named Monty
grumbled, "Testing RAM is a good way to bring up new processes, too.
Forcing the customer to scrimp on RAM is just a little anti-social."
Jeff
was also sketching something on note paper. "Separate address spaces.
We could put part of the direct page RAM in its own address space and
shave a cycle of access time for that RAM," he muttered, half to
himself.
"One thing I'd like to see in CPUs in general
is a way to catch things when calls or interrupts try to push too much
on the stack, and when return instructions try to pull too much off."
"How can you save state on the stack when the stack isn't valid?" Wayne asked in a tone that was almost rhetorical.
"I've
thought about limit registers that can be set to trigger when any
further push will leave no more room for an interrupt to save full state
without walking on variables."
Jeff looked up from his
sketching. "Shadow register sets that get switched in when handling
interrupts are a rather elegant solution to the stack overflow
conundrum."
"Speaking of the interrupt stack," an
engineer named Greg said, "stacking the U stack on interrupts will mess
with stack frame compatibility."
"That's part of the reason I call this ideal processor with conflicting specifications the 2805."
This drew chuckles from the engineers.
"Maybe it makes sense to not stack the parameter stack pointer
automatically, or maybe you need to use another name so the developers
know they need to make changes," Wayne nodded.
Bob chuckled. "So, while we're critiquing the 6805, is there anything else?"
"Not
enough I/O pins. We had to use either an external 8 bit latch or an
external multiplexor to read 64 keys. If we had a package with sixteen
more bits of I/O, we could decode larger keyboards without external
parts and still give a parallel interface to the main processor. Eight
more would work if the interface is serial."
Jeff
nodded. "Flatpack can give 64 pins in a reasonably small package.
Socketing those is expensive for now, but surface mount is cheap."
"Separate parts might be preferred?" I asked.
"Maybe."
"Anything else?" Bob prompted.
"Daydreaming time?" I laughed.
"Sure." He grinned.
"The
6801's eight-bit multiply is useful. An eight-bit pair of divides,
integer and fractional, might be useful, too. But I'm thinking about a
complete one-bit multiply and one-bit divide."
Bob furrowed his brow. "Single bit? That seems like swimming against the current."
"Software
multiplies spend a lot of time in branch instructions. If you could do a
full single-bit multiply with one instruction and stack those
instructions up, you could cut the time for a multiply in maybe a
quarter of the time of a software multiply, without the complexity of a
full multiplier circuit."
Greg responded. "Which
algorithm, and how are the arguments addressed? Several known pits to
fall into, but it might be worth looking at again."
Bill had picked up the Forth listing, and was looking at the first page.
"This is the license for using Forth?" he asked.
"For the Forth Interest Group's model interpreter," I replied
Monty
explained, "There are many Forth development systems with more
traditional licensing. The fig uses the liberal license and some of the
models are known to be a little buggy in places. In some cases, it's
almost as if they just threw code over the wall and abandoned it."
"How do you mean?" Bob asked.
"A liberal license requires an active development team to be useful. The development team can charge to fix bugs."
Bill laughed. "There's something cynical about that."
Monty
shrugged. "On the other hand, the user is also able to look for and fix
bugs. I saw this work at MIT. The group that works with the liberally
licensed LISP interpreters only allows contributions that are liberally
licensed into their code base. It's a rather elegant approach to
sharing. Code that doesn't get used doesn't get fixed."
Bill's forehead wrinkled. "Elegant and efficient. Hmm."
(I
should note, I was actually this prescient -- two or three years
later in my college career. And we must also assure ourselves that the
real engineers
who worked for the real Motorola were aware of pretty much all of this.
Which path was not clear. Management made decisions that, in hindsight,
were counterproductive.
Motorola's management and
engineers had no reason to talk with me like this in the real world,
much less believe me. But for this experiment to work, in the world of
this novel, they must.
Hindsight does seem to be
clearer than foresight, which is precisely the reason that this story is
something of a waste of time. But I think it's less a waste of time
than certain very popular classes of fiction that a lot of people waste a
lot of money on. Idolatry of idealized bodies and saccharin
personalities can't be more healthy than idolatry of idealized abstract
mathematical machines.)
[202008242104 -- original edit.]
Chapter 14.1: Rocks -- what?
[Backed up at https://joel-rees-economics.blogspot.com/2020/08/bk-33209-rocks-2805.html.]
