| Author |
Message |
keith
Guest
|
 Posted:
Sat Oct 29, 2005 5:51 am Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
On Sat, 29 Oct 2005 01:46:48 +0200, David Kastrup wrote:
| Quote: | "A Man Masterbating Alone In The Wilderness" <cpu16x1832@wmconnect.com> writes:
For an example the 69R000 Rad had microcontroller, doesn't use stacks
and saves all return addresses into a register, however, interrupts are
disabled with every call primitive, and must be.
But you can reenable them as soon as you have saved this register on
some stack.
|
It seems David has a problem disableing interrupts.
--
Keith |
|
| Back to top |
|
 |
keith
Guest
|
| Posted:
Sat Oct 29, 2005 5:53 am Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
On Fri, 28 Oct 2005 20:51:01 -0400, keith wrote:
| Quote: | On Sat, 29 Oct 2005 01:46:48 +0200, David Kastrup wrote:
"A Man Masterbating Alone In The Wilderness" <cpu16x1832@wmconnect.com> writes:
For an example the 69R000 Rad had microcontroller, doesn't use stacks
and saves all return addresses into a register, however, interrupts are
disabled with every call primitive, and must be.
But you can reenable them as soon as you have saved this register on
some stack.
It seems David has a problem disableing interrupts.
|
Shit! I meant Master Bator. Sorry!
--
Keith |
|
| Back to top |
|
|
maw
Guest
|
| Posted:
Sat Oct 29, 2005 7:51 am Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
A Man Masterbating Alone In The Wilderness wrote:
| Quote: | Frithiof Andreas Jensen wrote:
"A Man Crying Alone In The Wilderness" <cpu16x1832@wmconnect.com> wrote in
message news:1130080284.332527.14090@g14g2000cwa.googlegroups.com...
Which one do you believe requires less chip internal hardware wires?
( and, thus, a higher efficiency of "Turing" machine language
expression ( and code profile))
Why would I - or anyone else - even care when the Important Question is:
"Does Half Life run on it"??
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.
Oh, well, national security administration and big business rule.
Or, whether asychronous or syschronous is your game, name this tune, in
the least number of notes,
URL,
http://groups.google.com/group/comp.lang.java.machine/msg/b400d03ddc0f5a4f?dmode=source&hl=en
---
Virtue is the only goodness, however, where 'hording' rules, hero's
don't live long. Be a hero, anyway.
|
I believe the programmable multiplexer nodes ( the non-diagonal, ie not
the "enhanced stack machine" nodes along the diagonal) maybe the least
transistors for the greatest multiplexing efficiency.
Anyone else believe in eternity? |
|
| Back to top |
|
|
Casper H.S. Dik
Guest
|
| Posted:
Sat Oct 29, 2005 8:15 am Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
David Kastrup <dak@gnu.org> writes:
| Quote: | Nonsense. Do you have any experience with reentrant programming? The
interrupt routine has to restore all registers upon returning,
including the return address register. That's all.
|
Quite; and there are several architectures which only/mostly do register
passing: SPARC, AMD64... Any modern ABI, really.
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. |
|
| Back to top |
|
|
Jasen Betts
Guest
|
| Posted:
Sat Oct 29, 2005 2:45 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
["Followup-To:" header set to sci.electronics.design.]
On 2005-10-25, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
| Quote: | 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 |
|
| Back to top |
|
|
Jasen Betts
Guest
|
| Posted:
Sat Oct 29, 2005 2:54 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
["Followup-To:" header set to sci.electronics.design.]
On 2005-10-25, Alex Colvin <alexc@TheWorld.com> wrote:
| Quote: | 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?
| Quote: | 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 |
|
| Back to top |
|
|
Casper H.S. Dik
Guest
|
| Posted:
Sat Oct 29, 2005 3:18 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
<cpu16x1832@wmconnect.com> writes:
| Quote: | 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. |
|
| Back to top |
|
|
Casper H.S. Dik
Guest
|
| Posted:
Sat Oct 29, 2005 3:21 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
<cpu16x1832@wmconnect.com> writes:
| Quote: | 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. |
|
| Back to top |
|
|
Jerry Avins
Guest
|
| Posted:
Sat Oct 29, 2005 4:15 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
anonymous wrote:
| Quote: | Ken Smith wrote:
In article <pan.2005.10.26.17.27.43.715424@example.net>,
Rich Grise <rich@example.net> 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.
--
--
kensmith@rahul.net 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.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ |
|
| Back to top |
|
|
A Man Crying Alone In The
Guest
|
| Posted:
Sat Oct 29, 2005 10:29 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
Casper H.S. Dik wrote:
| Quote: | cpu16x1832@wmconnect.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?
| Quote: | 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.
| Quote: | 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. |
|
| Back to top |
|
|
Jerry Avins
Guest
|
| Posted:
Sun Oct 30, 2005 12:15 am Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
A Man Crying Alone In The Wilderness wrote:
...
| Quote: | 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.
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ |
|
| Back to top |
|
|
Geoff
Guest
|
| Posted:
Sun Oct 30, 2005 12:15 am Post subject:
Re: 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"
<cpu16x1832@wmconnect.com> wrote:
| Quote: |
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? |
|
| Back to top |
|
|
Guest
|
| Posted:
Sun Oct 30, 2005 5:15 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
In article <1130606965.410081.278220@g14g2000cwa.googlegroups.com>,
"A Man Crying Alone In The Wilderness" <cpu16x1832@wmconnect.com> wrote:
<snip>
| Quote: | 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 |
|
| Back to top |
|
|
Eric Pattison
Guest
|
| Posted:
Sun Oct 30, 2005 5:15 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
jmfbahciv@aol.com wrote:
| Quote: |
In article <1130606965.410081.278220@g14g2000cwa.googlegroups.com>,
"A Man Crying Alone In The Wilderness" <cpu16x1832@wmconnect.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 |
|
| Back to top |
|
|
Eric P.
Guest
|
| Posted:
Sun Oct 30, 2005 5:15 pm Post subject:
Re: A stupid post about Intel's latest computer chip ( s) |
|
|
jmfbahciv@aol.com wrote:
| Quote: |
In article <1130606965.410081.278220@g14g2000cwa.googlegroups.com>,
"A Man Crying Alone In The Wilderness" <cpu16x1832@wmconnect.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 |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in