A stupid post about Intel's latest computer chip ( s)

Posted: 2005-10-29 17:46:00

java-programmer, A stupid post about Intel's latest computer chip ( s) ["Followup-To:" header set to sci.electronics.design.]
On 2005-10-25, glen herrmannsfeldt <email***@***.com> wrote:
> Bruce McFarling wrote:
>
> (snip)
>

>> A stack does not have to be indexed in a stack machine processor. The
>> machine language primitives work directly on the stack. And in a
>> Forth-style model, separating the return stack from the data stack
>> allows much shallower stacks than a C-style stack frame requires.
>
> Does C require a combine stack? It is a common implementation, but
> I don't believe it is required.
>
> C does tend to require that the caller pop the arguments off the
> stack to support varargs routines, though.

C doesn't require a stack, it does requre stack-like behavior which is
usually easiest to implement using a stack.

ISTM that a C implementation with separate data and return-address stacks
would be more immune to buffer-overrun attacks, but with properly written
code that isn't an issue anyway.

Bye.
Jasen

Posted: 2005-10-29 17:46:00

java-programmer >> A stupid post about Intel's latest computer chip ( s) ["Followup-To:" header set to sci.electronics.design.]
On 2005-10-25, glen herrmannsfeldt <email***@***.com> wrote:
> Bruce McFarling wrote:
>
> (snip)
>

>> A stack does not have to be indexed in a stack machine processor. The
>> machine language primitives work directly on the stack. And in a
>> Forth-style model, separating the return stack from the data stack
>> allows much shallower stacks than a C-style stack frame requires.
>
> Does C require a combine stack? It is a common implementation, but
> I don't believe it is required.
>
> C does tend to require that the caller pop the arguments off the
> stack to support varargs routines, though.

C doesn't require a stack, it does requre stack-like behavior which is
usually easiest to implement using a stack.

ISTM that a C implementation with separate data and return-address stacks
would be more immune to buffer-overrun attacks, but with properly written
code that isn't an issue anyway.

Bye.
Jasen

Posted: 2005-10-29 17:55:00

java-programmer >> A stupid post about Intel's latest computer chip ( s) ["Followup-To:" header set to sci.electronics.design.]
On 2005-10-25, Alex Colvin <email***@***.com> wrote:
>>>> > Forth-style model, separating the return stack from the data stack
>>>> > allows much shallower stacks than a C-style stack frame requires.
>
> i don't see how this affects the space needed for a stack.
> it's just partitioned.
>

>>>> Does C require a combine stack? It is a common implementation, but
>>>> I don't believe it is required.
>
> no. in fact, the return address can be passed in a register.

yeah? how would recursion work?

> as for FORTH, doesn't it require two memory fetches for each interpreter
> cycle?

if the top end of the stacks are stored in special processor registers
that needn't be.

I've heard of forth implementations that run in machine code - define
something and the definition is stored as machine code that executes the
operations in the definition. would that be a compiler, or is it still an
interpreter?

Bye.
Jasen

Posted: 2005-10-29 18:18:00

java-programmer >> A stupid post about Intel's latest computer chip ( s) <email***@***.com> writes:

>I guess, maybe double non-sense,

>1) if a caller's address is only ever SAVED TO A REGISTER, then
>2) an interrupt occurs, before interrupts have been disabled AND the
>return address register has been saved, ...

>think simple, where does the previous program counter address go?

Well, I guess SPARC cannot possibly work then.....

This is all specific to a particular architecture; interrupts are
not exactly like calls; primarily because all registers are in use a
trap/interrupt cannot use *any* register which may be in use by an
application unless:

- the processor architecture defines a place to automatically save
such registers on a trap
or
- the processor architecture define a couple of "trap-only"
registers which store such things as "trap pc" and "trap sp"
which are restore on a "return from trap" instruction.

Modern ABIs all try to avoid using the stack to pass return address,
parameters and what not. Yet they all do reentrancy just fine.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Posted: 2005-10-29 18:22:00

java-programmer >> A stupid post about Intel's latest computer chip ( s) <email***@***.com> writes:

>I guess you missed my final post. "If a caller's address is only ever
>SAVED TO A REGISTER ...", anyway.

Nice strawman, that, but it won't cover your retreat.

That's not what the argument was about; most ABIs now pass the return
address in a register and not on the stack; and that does not stand in
the way of reentrancy as you claimed.

In fact, on SPARC all return address are only ever saved to a register
and no code in a program ever needs to store the return address, yet it
allows for stack depths/reentrancy as far as your VM limits allow.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Posted: 2005-10-29 22:42:00

java-programmer >> A stupid post about Intel's latest computer chip ( s) anonymous wrote:
> Ken Smith wrote:
>
>>In article <email***@***.com>,
>>Rich Grise <email***@***.com> wrote:
>>[....]
>>
>>>>no. in fact, the return address can be passed in a register.
>>>
>>>Not if you want reentrant code.
>>
>>I did re-entrant code on an 1802. You save the caller's address on the
>>"stack" when the routines starts up.
>>
>>
>>--
>>--
>>email***@***.com forging knowledge
>
>
> I guess the 1802 was without external interrupts, either the
> call-primitive should disable interrupts or it would be an interrupt
> frequency gamble?
>
> Or a reason they are not as popular ...
>
> ( ... I accidentally re-wired a 6502 where A X and Y are stacks !!!)
>
> Regards,
>
> maw

There is an external interrupt on the 1802. It forces the stack pointer
to R2, which most people (dangerously) used as the stack pointer anyway.
I used a different register assignment in code that needed interrupts,
reserving R2 for interrupts only and using separate interrupt stack
space. That way, there were no critical sections. The 1802 also
implemented simple but useful DMA, and the code for an autobaud bit
banger UART was in the monitor ROM. Say again why they were not so popular?

Jerry
--
Engineering is the art of making what you want from things you can get.
?

Posted: 2005-10-30 1:29:00

java-programmer >> A stupid post about Intel's latest computer chip ( s) Casper H.S. Dik wrote:
> <email***@***.com> writes:
>
> >I guess, maybe double non-sense,
>
> >1) if a caller's address is only ever SAVED TO A REGISTER, then
> >2) an interrupt occurs, before interrupts have been disabled AND the
> >return address register has been saved, ...
>
> >think simple, where does the previous program counter address go?
>
> Well, I guess SPARC cannot possibly work then.....
>

How so, doesn't SPARC disable interrupts AND push the return address
onto a stack on traps or have I been studying the wrong documentation?

> This is all specific to a particular architecture; interrupts are
> not exactly like calls; primarily because all registers are in use a
> trap/interrupt cannot use *any* register which may be in use by an
> application unless:
>
> - the processor architecture defines a place to automatically save
> such registers on a trap
> or
> - the processor architecture define a couple of "trap-only"
> registers which store such things as "trap pc" and "trap sp"
> which are restore on a "return from trap" instruction.
>

Even if an architecture defines "trap-only" registers, interrupts must
be disabled for interrupt sservice within the architecture to avoid
multi-trap collisions.

> Modern ABIs all try to avoid using the stack to pass return address,
> parameters and what not. Yet they all do reentrancy just fine.
>
> Casper
> --
> Expressed in this posting are my opinions. They are in no way related
> to opinions held by my employer, Sun Microsystems.
> Statements on Sun products included here are not gospel and may
> be fiction rather than truth.

Registers based architectures pre-date the use of stack based
architectures, so I guess it depends upon what you call modern. Stack
based architectures are, generally, twice as efficient for fabrication
where the goal is maximum circuit utilization.

Further, my balanced appoach to enhanced stack machine architecture is
a 16 element return stack, 8 element parameter stack, two 4 element
supplemental stacks and a thirty two element machine state/status
stack, as a minimum design.

There are sixteen extended stack machines operating in parallel and
using 240 machine forth micro-engines for performing 16 way to 16-way,
any-bus-to-any-bus, multiplxing. ( can you post a URL to a more
efficient multiplexing/multiplexer design anywhere on the web , plus
the sixteen parallel micro engines are already wired in for
multiplexing! )

A single CPU16 is sixteen parallel processors and every CPU is super
scalable with adding more CPUs. Show me ANY reference to a simpler and
more efficient multi core processor, and I will be the first to admit
my doubts,
URL,
http://groups.google.com/group/comp.lang.java.machine/msg/b400d03ddc0f5a4f?dmode=source&hl=en

Maybe the big money with the VLIW SMP MPP extended stack machine
architecture is NOT the CPU16 chip, but, mostly, the wide variety of
possible specialized versions of CPU16 with additional application
specific machine instruction primitives for example graphics ( Sony/IBM
Cell like primitives), floating point or data packet routing. These
/specialized/ version of the open VLIW SMP MPP extened stack machine
architecture design are the chips that will determine the final
performance level of computing, that is the limit of scalable
performance. Either bus masters, like CPU16, or bus terminators; for
example and FPU16 may also be super scalable, with hundred of
specialized FPU16s ( co-ordinating communications of thousands of
parallel FPUs.)
Or NET16s, IDE16s or VID16s, depending upon the application design
specifics.

---

An invention, by any other name, is an IBM product.

Posted: 2005-10-30 3:18:00

java-programmer >> A stupid post about Intel's latest computer chip ( s) A Man Crying Alone In The Wilderness wrote:

...

> Registers based architectures pre-date the use of stack based
> architectures, so I guess it depends upon what you call modern. Stack
> based architectures are, generally, twice as efficient for fabrication
> where the goal is maximum circuit utilization.

In what fabrication process?

...

Jerry
--
Engineering is the art of making what you want from things you can get.
?

Posted: 2005-10-30 8:04:00

java-programmer >> A stupid post about Intel's latest computer chip ( s) On 28 Oct 2005 17:26:51 -0700, "A Man Masterbating Alone In The Wilderness"
<email***@***.com> wrote:

>
>Going where no gamer has gone before ... super scalable multiple
>parallel symetric parallel processors ( with LEGO(tm) like
>expandability,) executing multi layered sprites and partion trees to
>drive more ultra hi resolution projection panels, and, so blindingly
>fast , a super computer beyond which no mere mortal could hope to
>survive.
>

OK, I'll bite. I see post and reposts of this incoherent blather going back
4 or 5 years, maybe more. I will put it in a form that can't possibly be
any more clear. I expect you can insert your answers in line.

Suppose I wanted to build a system based on this chip, where do I buy them,
how much do they cost?

Who fabricates them now, today?

Where can I buy a single-processor development kit?

What is the power consumption?

Where are the performance specifications and timing diagrams?

How is it interfaced to memory?

What are power supply and voltage requirements?

What are the pinouts?

Where's the data sheet?

What compilers are available for it?

Who makes them?

Who publishes new words and vocabularies for it?

How is it debugged?

What about realtime applications?

Interrupt services?

If it isn't real, now, here, today, when will it be made real?

Where are the VHDL or other sources for modeling and fabricating these
devices?

What is the web site of the fabricator and how many samples have they made?

Who are your customers and what systems have they produced based on this
design?

Posted: 2005-10-30 20:24:00

java-programmer >> A stupid post about Intel's latest computer chip ( s) In article <email***@***.com>,
"A Man Crying Alone In The Wilderness" <email***@***.com> wrote:
<snip>

>Even if an architecture defines "trap-only" registers, interrupts must
>be disabled for interrupt sservice within the architecture to avoid
>multi-trap collisions.

I'd consider that [disabling interrupts to handle each
interrupt] to be a big-time design bug. It doesn't deal
with interrupts that have a higher priority; if an interrupt
has a higher priority you have to catch it, not ignore it, let
alone disable it.

<snip>

/BAH

Posted: 2005-10-30 22:57:00

java-programmer >> A stupid post about Intel's latest computer chip ( s) email***@***.com wrote:
>
> In article <email***@***.com>,
> "A Man Crying Alone In The Wilderness" <email***@***.com> wrote:
> <snip>
>
> >Even if an architecture defines "trap-only" registers, interrupts must
> >be disabled for interrupt sservice within the architecture to avoid
> >multi-trap collisions.
>
> I'd consider that [disabling interrupts to handle each
> interrupt] to be a big-time design bug. It doesn't deal
> with interrupts that have a higher priority; if an interrupt
> has a higher priority you have to catch it, not ignore it, let
> alone disable it.

Some architectures only save one prior level of context.
E.g. a RISC processor would just copy the old program counter
and processor status value into a specific register pair,
disable interrupts and jam the interrupt address into the PC.
The interrupt routine preamble saves the prior state and reenables.

The RCA 1802 COSMAC, circa 1975, it was 5V CMOS (4000 series and
TTL compatible), with the power consumption directly porportional
to clock speed. You could stop the clock and draw only uAmps.

The architecturs had its own special brand of weirdness.
It had no stack NOR a formal program counter!
It was 16 bit address, 8 bit data, with an 8 register

Posted: 2005-10-30 23:08:00

java-programmer >> A stupid post about Intel's latest computer chip ( s) email***@***.com wrote:
>
> In article <email***@***.com>,
> "A Man Crying Alone In The Wilderness" <email***@***.com> wrote:
> <snip>
>
> >Even if an architecture defines "trap-only" registers, interrupts must
> >be disabled for interrupt sservice within the architecture to avoid
> >multi-trap collisions.
>
> I'd consider that [disabling interrupts to handle each
> interrupt] to be a big-time design bug. It doesn't deal
> with interrupts that have a higher priority; if an interrupt
> has a higher priority you have to catch it, not ignore it, let
> alone disable it.

Let me try that again
It seems accidental CarriageReturn = SendMessageNow.

Some architectures only save one prior level of context.
E.g. a RISC processor would just copy the old program counter
and processor status value into a specific register pair,
disable interrupts and jam the interrupt address into the PC.
The interrupt routine preamble saves the prior state and reenables.

The RCA 1802 COSMAC, circa 1975, it was 5V CMOS (4000 series and
TTL compatible), with the power consumption directly proportional
to clock speed. You could stop the clock and draw only uAmps.

The architecture had its own special brand of weirdness.
It had no stack NOR a formal program counter!
My memory may be a bit off, but IIRC...
It was 16 bit address, 8 bit data, with an 8 register bank.
There was a Program Counter Pointer (PCPR) register that
indicated which of the general registers was the program counter.
On interrupt, the PCPR was incremented and the next general
register was used as a program counter. It was up to the
interrupt routine to save the state as it required and
manipulate the registers and PCPR if it didn't want to use
up all the general registers saving prior program counters.

Eric

Posted: 2005-10-30 23:32:00

java-programmer >> A stupid post about Intel's latest computer chip ( s) Almost all of these questions have been answered, directly or
indirectly, through the messages I have written in various news groups,
simply perform a Google message options function of 'find messages by
author',
here is a link for simplicity's sake,
http://groups.google.com/groups?num=100&hl=en&lr=&ie=ISO-8859-1&scoring=d&q=dolphinconsultant+OR+mawcowboy+OR+cpu16x1832

You must ahve missthe the original post of this thread, however, in
very brief synopsis:

1) I wrote a letter to Washington in 1996 about a computer chip formula
for a very simply but powerful chip DESIGN, VLIW SMP MPP FORTH, I
recieved a 'personal' not interested vote from Microsoft Chairman Bill
Gates.

2) After feeling some pressure to 'continue to give away my idea to the
public', I wrote more letters to the same Washington people, telling
more about the theory and design ( and hoping they would stop riding my
ass), hundreds of pages of documentation where either email or faxed.

3) in the year 2000, Mr. Chuck Moore published information about his
25X work on the internet, I DISCOVERED his information and applied my
knowledge to form a hybrid chip design, Drum roll, please ...
URL,
http://groups.google.com/group/comp.lang.java.machine/msg/b400d03ddc0f5a4f?dmode=source&hl=en

RE,

---

Path:
g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc03.POSTED!befad20c!not-for-mail
From: Geoff <email***@***.com>
Newsgroups:
comp.lang.java.machine,comp.arch,comp.lang.forth,sci.math,sci.electronics.design
Subject: Re: A stupid post about Intel's latest computer chip ( s)
Message-ID: <email***@***.com>
References: <email***@***.com>
<djkuf4$r8h$email***@***.com>
<email***@***.com>
X-Newsreader: Forte Agent 3.1/32.783
X-No-Archive: yes
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 58
Date: Sun, 30 Oct 2005 00:03:50 GMT
NNTP-Posting-Host: 71.104.149.134
X-Complaints-To: email***@***.com
X-Trace: trnddc03 1130630630 71.104.149.134 (Sat, 29 Oct 2005 20:03:50
EDT)
NNTP-Posting-Date: Sat, 29 Oct 2005 20:03:50 EDT

On 28 Oct 2005 17:26:51 -0700, "A Man Masterbating Alone In The
Wilderness"
<email***@***.com> wrote:

>
>Going where no gamer has gone before ... super scalable multiple
>parallel symetric parallel processors ( with LEGO(tm) like
>expandability,) executing multi layered sprites and partion trees to
>drive more ultra hi resolution projection panels, and, so blindingly
>fast , a super computer beyond which no mere mortal could hope to
>survive.
>

OK, I'll bite. I see post and reposts of this incoherent blather going
back
4 or 5 years, maybe more. I will put it in a form that can't possibly
be
any more clear. I expect you can insert your answers in line.

Suppose I wanted to build a system based on this chip, where do I buy
them,
how much do they cost?

Who fabricates them now, today?

Where can I buy a single-processor development kit?

What is the power consumption?

Where are the performance specifications and timing diagrams?

How is it interfaced to memory?

What are power supply and voltage requirements?

What are the pinouts?

Where's the data sheet?

What compilers are available for it?

Who makes them?

Who publishes new words and vocabularies for it?

How is it debugged?

What about realtime applications?

Interrupt services?

If it isn't real, now, here, today, when will it be made real?

Where are the VHDL or other sources for modeling and fabricating these
devices?

What is the web site of the fabricator and how many samples have they
made?

Who are your customers and what systems have they produced based on
this
design?

Posted: 2005-10-30 23:35:00

java-programmer >> A stupid post about Intel's latest computer chip ( s)
Jerry Avins wrote:
> A Man Crying Alone In The Wilderness wrote:
>
> ...
>
> > Registers based architectures pre-date the use of stack based
> > architectures, so I guess it depends upon what you call modern. Stack
> > based architectures are, generally, twice as efficient for fabrication
> > where the goal is maximum circuit utilization.
>
> In what fabrication process?

The one that generates the most fortune for you!

>
> ...
>
> Jerry
> --
> Engineering is the art of making what you want from things you can get.
>

?

Posted: 2005-10-30 23:39:00

java-programmer >> A stupid post about Intel's latest computer chip ( s) Eric P. wrote:

> The RCA 1802 COSMAC, circa 1975, it was 5V CMOS (4000 series and
> TTL compatible), with the power consumption directly proportional
> to clock speed. You could stop the clock and draw only uAmps.
>
> The architecture had its own special brand of weirdness.
> It had no stack NOR a formal program counter!

One register was designated as the data pointer: register 2 by default
and forced by an interrupt. Register 1, IIRC was the default and
interrupt PC. Register 0 was the DMA pointer both in and out, and could
be general purpose. Small programs could jump to a subroutine simply by
naming a new register as PC. The first subroutine instruction passed
control to the main PC, and the last instruction jumped back to the
beginning. When set up, the subroutine PC pointed to the second
instruction. The 1802 had no CALL or RETURN op codes (the 1803 did).
Instead we used call and return subroutines, built as described. The
scheme designated a link register (so a subroutine could fetch immediate
data inlined in the main routine) and used the data pointer register as
a stack pointer. The link register was incremented in each data fetch,
so it pointed to the next instruction upon return. The contents of the
link register when the CALL subroutine was entered was pushed where the
data pointer (default: 3) designated, and restored by the RETURN
subroutine. My designs had four PC registers, main, interrupt, call,
and return. I designated separate interrupt and everything-else data
pointers, so avoiding critical sections. A really sweet machine, id
slow. In many ways, a PDP 11 invoked deja vu.

> My memory may be a bit off, but IIRC...
> It was 16 bit address, 8 bit data, with an 8 register bank.
> There was a Program Counter Pointer (PCPR) register that
> indicated which of the general registers was the program counter.
> On interrupt, the PCPR was incremented and the next general
> register was used as a program counter.

No. It was set to 1, I believe.

> It was up to the
> interrupt routine to save the state as it required and
> manipulate the registers and PCPR if it didn't want to use
> up all the general registers saving prior program counters.

I have a manual somewhere. Does anyone care?

Unless an interrupt is edge triggered, an interrupt must disable itself,
even if not all interrupts. Otherwise, asserting the interrupt would
lock up the machine and quickly overflow the stack.

Jerry
--
Engineering is the art of making what you want from things you can get.
?

Posted: 2005-10-30 23:43:00

java-programmer >> A stupid post about Intel's latest computer chip ( s)
email***@***.com wrote:
> In article <email***@***.com>,
> "A Man Crying Alone In The Wilderness" <email***@***.com> wrote:
> <snip>
>
> >Even if an architecture defines "trap-only" registers, interrupts must
> >be disabled for interrupt sservice within the architecture to avoid
> >multi-trap collisions.
>
> I'd consider that [disabling interrupts to handle each
> interrupt] to be a big-time design bug. It doesn't deal
> with interrupts that have a higher priority; if an interrupt
> has a higher priority you have to catch it, not ignore it, let
> alone disable it.
>
>
>
> <snip>
>
> /BAH

Something you may find interesting, in theory, my current circuit
theory doesn't include an interrupt system, only a /hardwired/ bus
service priority.
Software binding is performed with a bus id not an interrupt service
address, the bus id is /that/ address. ( a thought)

URL,
http://groups.google.com/group/comp.lang.java.machine/msg/b400d03ddc0f5a4f?dmode=source&hl=en

maw

Posted: 2005-10-31 0:07:00

java-programmer >> A stupid post about Intel's latest computer chip ( s) "Eric P." wrote:
>
> The architecture had its own special brand of weirdness.
> It had no stack NOR a formal program counter!
> My memory may be a bit off, but IIRC...
> It was 16 bit address, 8 bit data, with an 8 register bank.
> There was a Program Counter Pointer (PCPR) register that
> indicated which of the general registers was the program counter.
> On interrupt, the PCPR was incremented and the next general
> register was used as a program counter. It was up to the
> interrupt routine to save the state as it required and
> manipulate the registers and PCPR if it didn't want to use
> up all the general registers saving prior program counters.

Ah, I found a description of it.
It was a 16 register x 16 bit bank, 8 bit data.
SEP instruction set 4 bit P register pointer to the program counter.
SEX instruction set 4 bit X register pointer to the index register.
On interrupt P and X are copied to the 8 bit T register
and the forced to 1 and 2 respectively.
Nested interrupts required the programmer to save the
old PC and T values before reenabling interrupts.
There was other weirdness like to call a subroutine you load the
new PC address into a register and used SEP to change which register
was the program counter.

Because of low power and radiation hardness, the 1802 was used in
the Voyager, Viking, and Galileo spacecraft and many satallites.

Eric

Posted: 2005-10-31 2:29:00

java-programmer >> A stupid post about Intel's latest computer chip ( s) In article <email***@***.com>,
anonymous <email***@***.com> wrote:
>
>Ken Smith wrote:
[...]
>> I did re-entrant code on an 1802. You save the caller's address on the
>> "stack" when the routines starts up.
[...]
>I guess the 1802 was without external interrupts,

Others have well covered this.

>Or a reason they are not as popular ...

.. IIRC
AddAtoBandPutInC:
LDI low(A)
PLO 6
LDI high(A)
PLH 6
LDI low(B)
PLO 7
LDI high(B)
PLH 7
LDI low(C)
PLO 8
LDI high(C)
PLH 8

LDN 6
SEX 7
ADD
stn 8

16 instructions to get a simple C = A + B done is a big part of why it
isn't in common use today.

The ability to flip back and forth between co-routines by just doing one
instruction was sort of handy. It also made it easier to pass the address
of a subroutine.

--

Posted: 2005-10-31 3:51:00

java-programmer >> A stupid post about Intel's latest computer chip ( s) Ken Smith wrote:
> In article <email***@***.com>,
> anonymous <email***@***.com> wrote:
>
>>Ken Smith wrote:
>
> [...]
>
>>>I did re-entrant code on an 1802. You save the caller's address on the
>>>"stack" when the routines starts up.
>
> [...]
>
>>I guess the 1802 was without external interrupts,
>
>
> Others have well covered this.
>
>
>>Or a reason they are not as popular ...
>
>
> .. IIRC
> AddAtoBandPutInC:
> LDI low(A)
> PLO 6
> LDI high(A)
> PLH 6
> LDI low(B)
> PLO 7
> LDI high(B)
> PLH 7
> LDI low(C)
> PLO 8
> LDI high(C)
> PLH 8
>
> LDN 6
> SEX 7
> ADD
> stn 8
>
>
> 16 instructions to get a simple C = A + B done is a big part of why it
> isn't in common use today.

What's more, each instruction cycle took 8 clock cycles. With a 1 MHz
clock, that seems slow, but on one machine I built that controlled and
gathered data from an Auger spectrometer, averaging thousands of
readings and passing the results to a minicomputer when the run was
over, I slowed the clock to 250 KHz to assure robustness in the presence
of noise.

> The ability to flip back and forth between co-routines by just doing one
> instruction was sort of handy. It also made it easier to pass the address
> of a subroutine.

A real honey, for my part.

Jerry
--
Engineering is the art of making what you want from things you can get.
?

Posted: 2005-10-31 4:00:00

java-programmer >> A stupid post about Intel's latest computer chip ( s) In sci.math, Ken Smith
<email***@***.com>
wrote
on Sun, 30 Oct 2005 18:29:05 +0000 (UTC)
<dk33dh$rqt$email***@***.com>:
> In article <email***@***.com>,
> anonymous <email***@***.com> wrote:
>>
>>Ken Smith wrote:
> [...]
>>> I did re-entrant code on an 1802. You save the caller's address on the
>>> "stack" when the routines starts up.
> [...]
>>I guess the 1802 was without external interrupts,
>
> Others have well covered this.
>
>>Or a reason they are not as popular ...
>
> .. IIRC
> AddAtoBandPutInC:
> LDI low(A)
> PLO 6
> LDI high(A)
> PLH 6
> LDI low(B)
> PLO 7
> LDI high(B)
> PLH 7
> LDI low(C)
> PLO 8
> LDI high(C)
> PLH 8
>
> LDN 6
> SEX 7
> ADD
> stn 8
>
>
> 16 instructions to get a simple C = A + B done is a big part of why it
> isn't in common use today.
>
> The ability to flip back and forth between co-routines by just doing one
> instruction was sort of handy. It also made it easier to pass the address
> of a subroutine.
>

Yeah, but if it takes 32 cycles to do the equivalent of

ADD3B M1,M2,R0

(which e.g. the VAX could do easily enough), with each
cycle taking half a microsecond, it's not exactly the
fastest beastie in the world, though it was easy to play
with back then; it didn't really need all that much in
the way of support beyond a basic crystal oscillator. :-)

Ah, to think that a modern desktop could now probably
simulate the silly thing faster than it could actually
run back then...

--
#191, email***@***.com
It's still legal to go .sigless.

Posted: 2005-10-31 7:39:00

java-programmer >> A stupid post about Intel's latest computer chip ( s) The Ghost In The Machine wrote:

...

> Ah, to think that a modern desktop could now probably
> simulate the silly thing faster than it could actually
> run back then...

For sure! Later chips were faster -- I ran one with a 5 MHz clock, but
speed isn't important for a lot of applications. My .22 rifle shoots
bullets at about 1000 ft/sec. One gains a lot of perspective by quoting
execution times in inches.

The precursor COSMAC was called Fred. It was a toy built to run toys.
The architecture's hidden agenda was making it easy to write
interpreters, and the proof-of-concept implementation was in TTL, the
work of one man. Architectures had progressed from five addresses down
to one, and the design was intended to explore the possibilities of a
zero-address machine. It was the only prototype in the house when RCA
decided that they needed to come out with a microprocessor, and they ran
with it.

Jerry
--
Engineering is the art of making what you want from things you can get.
?