Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #1391 > unrolled thread

What are the various alternate uses for the PC's LSB ?

Back to article view | Back to comp.arch

Contents

  What are the various alternate uses for the PC's LSB ? whygee <yg@yg.yg> - 2011-05-08 23:01 +0200
    Re: What are the various alternate uses for the PC's LSB ? kym@kymhorsell.com - 2011-05-09 04:07 +0000
      Re: What are the various alternate uses for the PC's LSB ? whygee <yg@yg.yg> - 2011-05-09 08:45 +0200
    Re: What are the various alternate uses for the PC's LSB ? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-08 23:58 -0700
      Re: What are the various alternate uses for the PC's LSB ? whygee <yg@yg.yg> - 2011-05-09 09:02 +0200
        Re: What are the various alternate uses for the PC's LSB ? Quadibloc <jsavard@ecn.ab.ca> - 2011-05-09 09:43 -0700
      Re: What are the various alternate uses for the PC's LSB ? MitchAlsup <MitchAlsup@aol.com> - 2011-05-09 09:38 -0700
        Re: What are the various alternate uses for the PC's LSB ? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-09 11:14 -0700
        Re: What are the various alternate uses for the PC's LSB ? Anne & Lynn Wheeler <lynn@garlic.com> - 2011-05-09 14:51 -0400
    Re: What are the various alternate uses for the PC's LSB ? torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-05-09 16:31 +0200
      Re: What are the various alternate uses for the PC's LSB ? whygee <yg@yg.yg> - 2011-05-09 18:16 +0200
        Re: What are the various alternate uses for the PC's LSB ? mac <acolvin@efunct.com> - 2011-05-09 17:27 +0000
          Re: What are the various alternate uses for the PC's LSB ? whygee <yg@yg.yg> - 2011-05-09 19:38 +0200
            Re: What are the various alternate uses for the PC's LSB ? rpw3@rpw3.org (Rob Warnock) - 2011-05-09 20:23 -0500
              Re: What are the various alternate uses for the PC's LSB ? whygee <yg@yg.yg> - 2011-05-10 03:04 +0200
              Re: What are the various alternate uses for the PC's LSB ? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-11 14:23 -0700
                Re: What are the various alternate uses for the PC's LSB ? whygee <yg@yg.yg> - 2011-05-12 02:45 +0200
                  Re: What are the various alternate uses for the PC's LSB ? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-12 20:41 -0700
                    Re: What are the various alternate uses for the PC's LSB ? George Neuner <gneuner2@comcast.net> - 2011-05-14 23:24 -0400
                      Re: What are the various alternate uses for the PC's LSB ? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-15 09:18 -0700
                        Re: What are the various alternate uses for the PC's LSB ? Michael S <already5chosen@yahoo.com> - 2011-05-15 10:00 -0700
                          Re: What are the various alternate uses for the PC's LSB ? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-15 12:06 -0700
                            Re: What are the various alternate uses for the PC's LSB ? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-15 12:12 -0700
                              Re: What are the various alternate uses for the PC's LSB ? Michael S <already5chosen@yahoo.com> - 2011-05-15 16:16 -0700
                          Re: What are the various alternate uses for the PC's LSB ? nmm1@cam.ac.uk - 2011-05-15 20:58 +0100
                            Re: What are the various alternate uses for the PC's LSB ? Michael S <already5chosen@yahoo.com> - 2011-05-15 15:59 -0700
                              Re: What are the various alternate uses for the PC's LSB ? nmm1@cam.ac.uk - 2011-05-16 08:58 +0100
                              Re: What are the various alternate uses for the PC's LSB ? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-16 07:43 -0700
                                Re: What are the various alternate uses for the PC's LSB ? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-16 22:46 +0200
                          Re: What are the various alternate uses for the PC's LSB ? timcaffrey@aol.com (Tim McCaffrey) - 2011-05-19 16:13 +0000
                        Re: What are the various alternate uses for the PC's LSB ? George Neuner <gneuner2@comcast.net> - 2011-05-15 20:33 -0400
        Re: What are the various alternate uses for the PC's LSB ? whygee <yg@yg.yg> - 2011-05-11 05:53 +0200
          Re: What are the various alternate uses for the PC's LSB ? whygee <yg@yg.yg> - 2011-05-11 07:10 +0200
    Re: What are the various alternate uses for the PC's LSB ? Quadibloc <jsavard@ecn.ab.ca> - 2011-07-04 09:39 -0700
      Re: What are the various alternate uses for the PC's LSB ? Quadibloc <jsavard@ecn.ab.ca> - 2011-07-04 10:23 -0700

Page 2 of 2 — ← Prev page 1 [2]

#1591

On May 15, 6:18 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net>
wrote:
> The i960 legacy moved to  Arizona.
>

I still don't understand why they killed i960 that, by the time of
decision, was the best-selling 32-bit RISC CPU, in favor of ARM, that,
outside of handheld niche,  hardly had any presence at all in embedded
CPU world.
Who was a genius that made this decision?

[toc] | [prev] | [next] | [standalone]

#1593

On 5/15/2011 10:00 AM, Michael S wrote:
> On May 15, 6:18 pm, "Andy \"Krazy\" Glew"<a...@SPAM.comp-arch.net>
> wrote:
>> The i960 legacy moved to  Arizona.
>>
>
> I still don't understand why they killed i960 that, by the time of
> decision, was the best-selling 32-bit RISC CPU, in favor of ARM, that,
> outside of handheld niche,  hardly had any presence at all in embedded
> CPU world.
> Who was a genius that made this decision?

I don't know.

All I know is that in 2002 I considered doing Intel ARM Xscale 
architecture, to the point of househunting in Arizona, but decided not 
to because I felt that Intel would never allow ARM/Xscale to compete 
against x86 - and  that was inevitably where ARM was  heading.  In the 
form of smart phones and tablets, real computers that just happened to 
be in really low power and small form factors.

Instead I went to AMD in 2002.

Selling Xscale to Marvell happened quite a bit later, in 2006.  Heck, I 
had returned to Intel by then.

[toc] | [prev] | [next] | [standalone]

#1594

On 5/15/2011 12:06 PM, Andy "Krazy" Glew wrote:
> On 5/15/2011 10:00 AM, Michael S wrote:
>> On May 15, 6:18 pm, "Andy \"Krazy\" Glew"<a...@SPAM.comp-arch.net>
>> wrote:
>>> The i960 legacy moved to Arizona.
>>>
>>
>> I still don't understand why they killed i960 that, by the time of
>> decision, was the best-selling 32-bit RISC CPU, in favor of ARM, that,
>> outside of handheld niche, hardly had any presence at all in embedded
>> CPU world.
>> Who was a genius that made this decision?
>
> I don't know.
>
> All I know is that in 2002 I considered doing Intel ARM Xscale
> architecture, to the point of househunting in Arizona, but decided not
> to because I felt that Intel would never allow ARM/Xscale to compete
> against x86 - and that was inevitably where ARM was heading. In the form
> of smart phones and tablets, real computers that just happened to be in
> really low power and small form factors.
>
> Instead I went to AMD in 2002.
>
> Selling Xscale to Marvell happened quite a bit later, in 2006. Heck, I
> had returned to Intel by then.


Woops, I thought you were talking about "Why did Intel abandon 
ARM/Xscale?", rather than "Why did Intel abandon i960 and pick up 
ARM/XScale?"

No insight there either, except to note that Intel has limited mindshare 
for anything non-x86, non-PC, non-server.

[toc] | [prev] | [next] | [standalone]

#1597

On May 15, 10:12 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net>
wrote:
> On 5/15/2011 12:06 PM, Andy "Krazy" Glew wrote:
>
>
>
> > On 5/15/2011 10:00 AM, Michael S wrote:
> >> On May 15, 6:18 pm, "Andy \"Krazy\" Glew"<a...@SPAM.comp-arch.net>
> >> wrote:
> >>> The i960 legacy moved to Arizona.
>
> >> I still don't understand why they killed i960 that, by the time of
> >> decision, was the best-selling 32-bit RISC CPU, in favor of ARM, that,
> >> outside of handheld niche, hardly had any presence at all in embedded
> >> CPU world.
> >> Who was a genius that made this decision?
>
> > I don't know.
>
> > All I know is that in 2002 I considered doing Intel ARM Xscale
> > architecture, to the point of househunting in Arizona, but decided not
> > to because I felt that Intel would never allow ARM/Xscale to compete
> > against x86 - and that was inevitably where ARM was heading. In the form
> > of smart phones and tablets, real computers that just happened to be in
> > really low power and small form factors.
>
> > Instead I went to AMD in 2002.
>
> > Selling Xscale to Marvell happened quite a bit later, in 2006. Heck, I
> > had returned to Intel by then.
>
> Woops, I thought you were talking about "Why did Intel abandon
> ARM/Xscale?", rather than "Why did Intel abandon i960 and pick up
> ARM/XScale?"
>
> No insight there either, except to note that Intel has limited mindshare
> for anything non-x86, non-PC, non-server.

When I first came int the industry in early 90s, Intel still was very
respected producer of embedded parts. Yes, they already lost 8-bit
battle to 8051-compatibles from other vendors. But they had '196 - on
of the best 16-bit uC families, i960 - leading 32-bit RISC, even 80186
was still alive, although AMD killed it with AM186 soon thereafter.
Even i860 was not a total failure in embedded world - Intel sold quite
a few for high-end digital signal processing. Many embedded designers
liked its peak FLOPs that were higher than contemporary C30 and C40
DSPs from TI and relied on Intel, 3rd party or home-made hand-coded
libraries to get reasonable utilization.
Then Intel embedded CPUs started to fade, but they still were very
important to the industry as a leading supplier of NOR flash.
No more.

[toc] | [prev] | [next] | [standalone]

#1595

In article <2ff8abad-a3a2-4e4b-8aae-4367e4132ae7@l18g2000yql.googlegroups.com>,
Michael S  <already5chosen@yahoo.com> wrote:
>On May 15, 6:18=A0pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net>
>wrote:
>
>> The i960 legacy moved to  Arizona.
>
>I still don't understand why they killed i960 that, by the time of
>decision, was the best-selling 32-bit RISC CPU, in favor of ARM, that,
>outside of handheld niche,  hardly had any presence at all in embedded
>CPU world.
>Who was a genius that made this decision?

I don't think that you have your facts quite right.  By the time
that the i960 was killed, 32-bit cpus were obviously yesterday's
technology for desktops and even some of the high-end embedded
market, and ARM was being increasingly used in many of the high
volume embedded markets (NOT just handheld).  My reading is that
it lost out politically within Intel for for the following (bad)
reasons:

    The x86 brigade had persuaded the executives that Microsoft
would except nothing else, and nothing else mattered, on the
desktop and in servers.

    The ARM brigade had (arguably correctly) claimed that it was
he best solution for mass-market embedded CPUs, and Intel has
never really understood the high-performance embedded market.

    The i960 brigade had failed to persuade the executives either
that there was another market or that it was a better long-term
solution than an ARM/x86 combination.


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#1596

On May 15, 10:58 pm, n...@cam.ac.uk wrote:
> In article <2ff8abad-a3a2-4e4b-8aae-4367e4132...@l18g2000yql.googlegroups.com>,
> Michael S  <already5cho...@yahoo.com> wrote:
>
> >On May 15, 6:18=A0pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net>
> >wrote:
>
> >> The i960 legacy moved to  Arizona.
>
> >I still don't understand why they killed i960 that, by the time of
> >decision, was the best-selling 32-bit RISC CPU, in favor of ARM, that,
> >outside of handheld niche,  hardly had any presence at all in embedded
> >CPU world.
> >Who was a genius that made this decision?
>
> I don't think that you have your facts quite right.  By the time
> that the i960 was killed, 32-bit cpus were obviously yesterday's
> technology for desktops

Questionable, but doesn't matter. That's not where i960 or ARM was
sold.

> and even some of the high-end embedded market,

So tiny part of embedded market that it obviously didn't matter. Even
today, something like 13 years later, 32-bit embedded CPUs outsell 64-
bitters by huge factors and majority of 64-bitters (mostly MIPS 4K
derivatives) also run 32-bit apps.
And, of course, i960, being under full Intel control, was much easier
(than ARM) to extend to 64 bits when the need emerges.

> and ARM was being increasingly used in many of the high
> volume embedded markets (NOT just handheld).  

We are talking about 1997-98. By then ARM had very little penetration
into "headless" embedded, esp. to medium-to-low volume where you have
a lot of relatively small customers and could achieve very good
margins - exactly what Intel likes.

>My reading is that it lost out politically within Intel for for the following (bad)
> reasons:
>
>     The x86 brigade had persuaded the executives that Microsoft
> would except nothing else, and nothing else mattered, on the
> desktop and in servers.

But x86 embedded was starved of resources similarly or worse than
i960. At least i960 had circa-1992 uArch. Intel embedded x86 CPUs, on
the other hand, were stuck in 1985 tech and never allowed even into
i486 age.

>
>     The ARM brigade had (arguably correctly) claimed that it was
> he best solution for mass-market embedded CPUs, and Intel has
> never really understood the high-performance embedded market.
>

StrongArm, in a form it came from DEC, was crap. Decent CPU, but
pathetic peripherals. Too little options, too, And in embedded word
people care about the total packet, not just CPU. More often than not,
CPU is one of the less important parts. It took something like 5 years
to convert it to something Intel could sell, barely. By then the
momentum they had with i960 was totally lost.
The only Intel ARM line that was selling  relatively well was PXA
line, which was intended for handhelds and similar semi-embedded semi-
general-purpose devices. I.e. something that didn't compete directly
with i960 but would rather complement i960 offerings were they not
dead by that time.

>     The i960 brigade had failed to persuade the executives either
> that there was another market or that it was a better long-term
> solution than an ARM/x86 combination.
>

That's the thing I don't understand. The theory say that, other things
being equal, home-grown solution wins. And here home-grown solution
lost despite being much bigger, rather than equal. Sort of NIH
syndrome in reverse..

[toc] | [prev] | [next] | [standalone]

#1604

In article <8e9433b8-01f5-4b8e-814a-805e269ff292@t19g2000yql.googlegroups.com>,
Michael S  <already5chosen@yahoo.com> wrote:
>>
>> I don't think that you have your facts quite right.  By the time
>> that the i960 was killed, 32-bit cpus were obviously yesterday's
>> technology for desktops
>
>Questionable, but doesn't matter. That's not where i960 or ARM was
>sold.

No, but Intel could and arguably should have corrected that.

>> and even some of the high-end embedded market,
>
>So tiny part of embedded market that it obviously didn't matter. Even
>today, something like 13 years later, 32-bit embedded CPUs outsell 64-
>bitters by huge factors and majority of 64-bitters (mostly MIPS 4K
>derivatives) also run 32-bit apps.

Er, no.  I was speaking to someone last week who had been involved
with a large company that was happy if it made 3 sales in a year.
At the high end of the embedded market, a single system may be
millions or even tens of millions of dollars - think extreme
aircraft control, chemical and nuclear plant control and so on.
Small turnover, big money, even by Intel's standards.  That's
where HPC meets embedded, after all :-)

>> and ARM was being increasingly used in many of the high
>> volume embedded markets (NOT just handheld).  
>
>We are talking about 1997-98. By then ARM had very little penetration
>into "headless" embedded, esp. to medium-to-low volume where you have
>a lot of relatively small customers and could achieve very good
>margins - exactly what Intel likes.

Hmm.  Not according to my sources in that area.

>>     The x86 brigade had persuaded the executives that Microsoft
>> would except nothing else, and nothing else mattered, on the
>> desktop and in servers.
>
>But x86 embedded was starved of resources similarly or worse than
>i960. At least i960 had circa-1992 uArch. Intel embedded x86 CPUs, on
>the other hand, were stuck in 1985 tech and never allowed even into
>i486 age.

I didn't say embedded.  What I meant was that the "Microsoft rules
the wage slaves" brigade blocked the i960 from being produced for
the desktop, server and HPC markets.  So it couldn't expand into
that area.  We heretics (Linux and other) would have bought, and
you know how things have developed there.

>>     The ARM brigade had (arguably correctly) claimed that it was
>> he best solution for mass-market embedded CPUs, and Intel has
>> never really understood the high-performance embedded market.
>
>StrongArm, in a form it came from DEC, was crap. Decent CPU, but
>pathetic peripherals. Too little options, too, And in embedded word
>people care about the total packet, not just CPU. ...

I am not arguing.  What does politics have to do with engineering?

>>     The i960 brigade had failed to persuade the executives either
>> that there was another market or that it was a better long-term
>> solution than an ARM/x86 combination.
>
>That's the thing I don't understand. The theory say that, other things
>being equal, home-grown solution wins. And here home-grown solution
>lost despite being much bigger, rather than equal. Sort of NIH
>syndrome in reverse..

My explanation is that it was simply an internal power struggle
within Intel, and political success depends on a lot of irrational
factors.  There are recorded instances in other environments where
it came down to who was shagging who's spouse.


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#1618

On 5/15/2011 3:59 PM, Michael S wrote:

>
> That's the thing I don't understand. The theory say that, other things
> being equal, home-grown solution wins. And here home-grown solution
> lost despite being much bigger, rather than equal. Sort of NIH
> syndrome in reverse..

I call it the NNIH syndrome - the not-not-invented-here syndrome.  Intel 
has it in spades.   It is usually easier to persuade Intel management 
that something from outside the company is better than something home grown.

[toc] | [prev] | [next] | [standalone]

#1622

Andy "Krazy" Glew wrote:
> On 5/15/2011 3:59 PM, Michael S wrote:
>
>>
>> That's the thing I don't understand. The theory say that, other things
>> being equal, home-grown solution wins. And here home-grown solution
>> lost despite being much bigger, rather than equal. Sort of NIH
>> syndrome in reverse..
>
> I call it the NNIH syndrome - the not-not-invented-here syndrome. Intel
> has it in spades. It is usually easier to persuade Intel management that
> something from outside the company is better than something home grown.

BT, DT:

Me and a coworker once promised we could write a working prototype of a 
distributed realtime system in a month, and we'd need 3 months for the 
3-way redundant version.

The directors decided that it was safer to outsource it. :-(

We begged our boss, who relented and gave us three days:

During that time we wrote the entire system on two PCs: One PC had the 
production code with nice fancy displays showing a realtime situation 
plot, with drilldown, while the other PC emulated all the system hw that 
we didn't have at the time, including programmable error rates for every 
component and a tracker which showed any differences this resulted in 
between the real situation and what the production display was currently 
showing. I.e. any offset due to component errors.

We showed off this, and the directors decided that since Mobile Oil had 
told them that a calendar year was the minimum time to implement such a 
solution (independent of the number of hw/sw people), they would still 
get a nice written contract with a British Joint Venture company who 
could deliver both hw and sw.

Terje
PS. A year later I had to spend 7 weeks in NE England trying to teach 
them realtime programming, before I realized that they couldn't make the 
hardware work either. :-(
-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[toc] | [prev] | [next] | [standalone]

#1693

In article 
<2ff8abad-a3a2-4e4b-8aae-4367e4132ae7@l18g2000yql.googlegroups.com>, 
already5chosen@yahoo.com says...
>
>On May 15, 6:18=A0pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net>
>wrote:
>> The i960 legacy moved to  Arizona.
>>
>
>I still don't understand why they killed i960 that, by the time of
>decision, was the best-selling 32-bit RISC CPU, in favor of ARM, that,
>outside of handheld niche,  hardly had any presence at all in embedded
>CPU world.
>Who was a genius that made this decision?


My recollection was that the i960 was originally supposed to be a "Unix" class 
workstation processor.  When someone in Intel figured out this could impact 
x86 sales the processor was retargetted to embedded.

We built a board with a i960 and a MIPS embedded processor on it.  Why? Well, 
the i960 had a nice non-transparent bridge & data mover and the MIPS had the 
performance.  Later versions of the board dropped the i960 for an FPGA.

By the time Intel dropped the i960, the XScale line was popular with HBA and 
smart NIC vendors (e.g. Adaptec, EMC, LSI, etc.).  And, really, the latest 
XScale IOP processors are pretty decent (for HBA use).

There was even a company that built a Micro ATX sized motherboard based on one 
of the IOPs.

Without investment, the i960 just lacked the performance to compete with other 
embedded solutions, and I think it was out-performed by StrongARM (i.e. 
XScale) from the day Intel inheirited from DEC.

		- Tim

[toc] | [prev] | [next] | [standalone]

#1598

On Sun, 15 May 2011 09:18:28 -0700, "Andy \"Krazy\" Glew"
<andy@SPAM.comp-arch.net> wrote:

>On 5/14/2011 8:24 PM, George Neuner wrote:
>> On Thu, 12 May 2011 20:41:06 -0700, "Andy \"Krazy\" Glew"
>> <andy@SPAM.comp-arch.net>  wrote:
>>
>>> I started looking for a manual that had been scanned and put up,
>>> and found this:
>>>
>>>     http://pages.swcp.com/~mccurley/humor/i860.html
>>>     Our favorite manual
>>>
>>>     (Intel i860 Processor Reference Manual)
>>>
>>>     Bullet holes courtesy of Stephen Wheat,
>>>     one of the chief architects of SUNMOS.
>>>     It should be noted that he now works for Intel!
>>>
>>> Unfortunately, can't find the manual.  Maybe I can scan it in.  If Intel
>>> will permit it.
>>
>> I may be completely mistaken here - it's been a long while - but my
>> recollection was that, modulo FP and MMU, the i860 and i960 were
>> instruction set compatible.
>>
>> The i960 manuals and datasheets seem still to be available.  Would
>> they be of any use?
>>
>> George
>
>
>The i860 and the i960  are about as instruction set incompatible as can be.
>
>The i960 was a RISC (actually, it may have predated RISC).  Well 
>behaved, sequential instruction semantics, although it had superscalar 
>implementations that preserved such semantics.  Where it went overboard 
>was with object oriented system programming extensions.  One of my 
>friends was known as the expert on garbage collection in the i960 microcode.
>
>The i860 expossed its pipeline.  Something along the lines of VLIW.  It 
>had a push pipeline, e.g. some operations results would not get written 
>out automatically, unless you stuffed extra elements into the pipeline 
>to "push" them out.
>
>Short:
>
>i960: pleasant for assembly language.
>
>i860: damnably hard for assembly language and compilers - the sort of 
>processor whose manual you might shoot at in a target range in 
>celebration that you no longer have to deal with it.
>
>The i960 team in Oregon became the P6 team. (The i960 legacy movedto 
>Arizona.)
>
>The i860 in California was the philosophical heart of the attitude that 
>gave us Itanium.
>
>---
>
>This is not to say that there were not neat ideas in the i860, 
>particularly in Les Kohn's later, cancelled, versions.


Thanks for the correction.   I am fairly certain, though, that there
was an integer-only analog of the i860.  Do you know offhand what was
that chip?

George

[toc] | [prev] | [next] | [standalone]

#1433

whygee wrote:
> {{ As I reread before hitting "send", I imagine a different approach
> where the CPU hangs/traps whenever a 1 is written to the LSB,
> which could be useful for debugging and breakpointing }}
> 
> {{ Now I'm even more curious : has anyone ever used the PC's LSB for 
> breakpoints ? }}

The more i think about it, the more it strikes me as a
good solution as it solves many issues I had.
The trick is to not see the unused save-restore as a waste.
and there is no consistency to maintain on the data bus.

If I define a set LSB as a trap condition, then users will
avoid triggering it. Then, IF the need arises, the trap can
be repurposed or even the bit itself could change behaviour.

Any comment, advice, remark, insight or drawback I missed ?

yg
-- 
http://ygdes.com / http://yasep.org

[toc] | [prev] | [next] | [standalone]

#1434

sorry for quoting myself again but...

whygee wrote:
> If I define a set LSB as a trap condition, then users will
> avoid triggering it. Then, IF the need arises, the trap can
> be repurposed or even the bit itself could change behaviour.
> 
> Any comment, advice, remark, insight or drawback I missed ?

One OBVIOUS use for an address bit is ...
to point to more addresses :-D

The LSB of the instruction pointer can be used
to designate an alternate program memory range.
The YASEP exists as 32 bits or 16 bits wide datapath versions
and the width of pointers equals the data width so the 16-bit
version will easily run out of program memory space.
Being able to address 64K instructions
instead of 32K is a little but good win :-)
And it's less ugly than how the PIC16F
or the Rabbit architecture do.

Only drawback : PC-relative data access will wrap around
in the 64K bytes of data space.

This system won't work with the 32-bit version so it should trap anyway...

yg
-- 
http://ygdes.com / http://yasep.org

[toc] | [prev] | [next] | [standalone]

#2355

On May 8, 3:01 pm, whygee <y...@yg.yg> wrote:

> So can people here tell me what other uses of this LSB have
> been tried in the past ?

Most older computers had a program counter that matched the length of
instructions, so there was no extra bit available. On the x86,
instructions can be an odd number of bytes long, so they start on any
byte.

But there have been cases where interesting things did happen.

I just came across an old computer today where there were two repeat
instructions. One repeated either the next instruction or the next two
instructions, depending on whether the repeat instruction fell on an
even or odd address. The other repeated either the next three
instructions or the next four the same way.

John Savard

[toc] | [prev] | [next] | [standalone]

#2356

On Jul 4, 10:39 am, I wrote:

> I just came across an old computer today where there were two repeat
> instructions. One repeated either the next instruction or the next two
> instructions, depending on whether the repeat instruction fell on an
> even or odd address. The other repeated either the next three
> instructions or the next four the same way.

It took me a while to find it again; it was the Philco 212 that did
this.

John Savard

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.arch

csiph-web