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 1 of 2  [1] 2  Next page →

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

Hello,

I hope that the old guard here can provide some wisdom and knowledge :-)

In the context of a fixed-size instruction and byte-oriented computer architecture,
such as ARMv7, MIPS, SPARC and so on, the Least Significant Bit of the instruction
pointer is wasted and cleared.

ARM Thumb uses it to define the current instruction set mode,
which makes a lot of sense for them.

In the YASEP architecture that I develop, this bit stores the Carry flag, which
makes quite a lot of sense here too, as I don't need a f***ing status register
for any other reason.

However, as I'm defining the YASEP further,
I'm still unsure it's the absolute best idea.
This method implies some added logic to write to
and read from the Instruction Pointer register :-/
OTOH I don't know how I could replace this solution
elegantly since it saves instructions and simplifies others.

Other uses of this sticky bit have been examined :
  - Switch to alternate register sets ? Nah, no need since I can simply switch to
      a whole new hardware thread on demand.
  - Switch from 16-bits to 32-bits mode ? Nah, this bit should be kept in the thread's
      attribute register. Jumping back and forth would mess with address mappings and ranges.
  - I have no need of parity, odd/even, sign, overflow or other computational attributes
     since i can reconstruct most of them by reading a given register.

I don't know what other "mode" information could be stored in this handy bit,
which would be more compelling than the carry/borrow result.
So can people here tell me what other uses of this LSB have
been tried in the past ?

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

[toc] | [next] | [standalone]

#1393

whygee <yg@yg.yg> wrote:
> Hello,
> I hope that the old guard here can provide some wisdom and knowledge :-)
> In the context of a fixed-size instruction and byte-oriented computer architecture,
> such as ARMv7, MIPS, SPARC and so on, the Least Significant Bit of the instruction
> pointer is wasted and cleared.
...

I think you are being misled by the "programmers view" of the architecture.

Normally such an "always 0" lsb bit (or these days a couple of lsb bits)
is not present in the h/w at all.  There is nothing to "store there".
There is no storage "wasted".

But that said, it's possible to make any bit whatever *appear* in the lsb
of a "register". There might be some problems with the IP/PC in particular
because it's always changing and therefore co-ordinating the "correct" value
of the chosen bit with the "present" value of the PC it's supposed to be
associated with may be tricky. E.g. you might end up with this lsb sometimes
and sometimes not associated with the IP value less 1 (word), or the address
before the last jump, subroutine call, trap, interrupt, mode change or...

The main question before a single extra wire is strung -- why would anyone
reasonably want to do it. "Pedagogic neatness" normally doesn't count as a reason.

It would seem having the state of (e.g.) the carry flag appear together
with the word addr of the instruction that changed it (or maybe sometimes
the instruction before or after that one ;) might be useful only in a very
small number of codes. It's generally the case the PC isn't needed if you
actually have the "PSW" in a "register" someplace (or whatever else
if you don't like notional registers storing arithmetic status bits).

Picking out a single status bit from all the 100s that you could choose
from also seems a bit arbitrary.

Anyway, for applications such as instruction roll-back there are usually
s/w-wise simpler and more complete ways to get status bits back to
the state they were when e.g. an instruction trapped.

--
Scientists are always changing their story and as a Conservative, I
have no tolerance for ambiguity.  It proves that all science is lies and
the only thing we can trust is right wing rhetoric.
  -- BONZO@27-32-240-172 [86 nyms and counting], 14 Jan 2011 14:46 +1100

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

#1395

Hi Kym,
there are a few interesting points in your answer
and I'll try to address them.

kym@kymhorsell.com wrote:
> I think you are being misled by the "programmers view" of the architecture.
maybe I expressed myself imprecisely :-)

> Normally such an "always 0" lsb bit (or these days a couple of lsb bits)
> is not present in the h/w at all.  There is nothing to "store there".
> There is no storage "wasted".

Sure, but it depends on the architecture : whether PC/IP is register-set mapped
(like ARM or RCA1802) or not (x86, MIPS...)
The YASEP belongs to the first category, where each user-visible bit
in the register set is precious (must be wisely allocated) and saveable/restorable.

On MIPS-likes for example, the IP/PC is not user visible so the LSB is not wired.
It does not even go on the user-visible data bus.
But on ARM (for example) the bit is available, visible and it's a waste
to not use it. And it is used nowadays.

> But that said, it's possible to make any bit whatever *appear* in the lsb
> of a "register".
sure, "it's just wires and MUXes" :-)

 > There might be some problems with the IP/PC in particular
> because it's always changing and therefore co-ordinating the "correct" value
> of the chosen bit with the "present" value of the PC it's supposed to be
> associated with may be tricky. E.g. you might end up with this lsb sometimes
> and sometimes not associated with the IP value less 1 (word), or the address
> before the last jump, subroutine call, trap, interrupt, mode change or...
right too.
I think i can handle it (it's not a superscalar superpipelined CPU with complex
forwarding) but it's a potential issue to keep in mind.

> The main question before a single extra wire is strung -- why would anyone
> reasonably want to do it. "Pedagogic neatness" normally doesn't count as a reason.

it's a complex choice, I succeeded in getting rid of all the usual "status bits"
through architectural (ISA and structure) compromises
but the carry/borrow resisted my attempts at finding a decent
solution that fits all my requirements and constraints.
So I had to put that bit somewhere and the "NIP" (Next Instruction Pointer)
looks like the only available choice (instructions are aligned on 16-bits boundaries).

And yes, NIP is both readable and writeable by the program,
so I got rid of the jump/branch/return instructions.
Just write the address to NIP.
I also don't have load/store instructions either, in a
CDC6600-reminiscent style.

> It would seem having the state of (e.g.) the carry flag appear together
> with the word addr of the instruction that changed it (or maybe sometimes
> the instruction before or after that one ;) might be useful only in a very
> small number of codes.
Hmmm I never looked at this this way...
In my head, these things are decoupled :
the jump/return instruction address (as stored in memory or
another register) has no relationship with the carry,
the lifetime of these informations are too different
AND are they serve different purposes.
So normally the LSB/Carry is only affected by the Adder's output
when performing a certain set of opcodes (add, sub and compare).


> It's generally the case the PC isn't needed if you
> actually have the "PSW" in a "register" someplace (or whatever else
> if you don't like notional registers storing arithmetic status bits).

well, some of the rules of the YASEP architecture are :
  - all important registers are mapped in a single register space,
      which has 16 addresses only, and the others less used are in a separate larger space.
  - no register-specific instruction (to keep the instruction set simple, small etc.)
      and the large, slow register space is accessed through "get" and "put" instructions only

As a result I have about 40 opcodes defined out of a space of 64.
I'm not eager to eat up that remaining space :-)

> Picking out a single status bit from all the 100s that you could choose
> from also seems a bit arbitrary.

it could seem so but i don't have much choice left,
I just want to be sure it's the best choice.

> Anyway, for applications such as instruction roll-back there are usually
> s/w-wise simpler and more complete ways to get status bits back to
> the state they were when e.g. an instruction trapped.

hmmmm it's not a problematic scenario, since the carry and NIP share
a place, but they can be decoupled in time. They just get together
at the same time and space on the register read buses when
they are read as part of an instruction or when register bank switch occurs.

It is just a side effect that C is saved along NIP on the stack
during procedure calls (for example) because the merge data go through
the datapath like any other normal register. When returning,
the instruction is just a "MOV" to the NIP register, which does
not alter the C (well it could but i see no point)

Furthermore I belong to the school of thoughts that says that instructions
should not enter the pipeline if they could trap, because roll-back is so messy ;-P
Usually, at decode time and with the right ISA, there are enough informations
(including speculatively computed flags) to decide to trap right away.
For example, memory addresses are computed in a separate instruction
from the one that performs the effective access.

In other architectures I could afford the luxury of 2R2W or 3R1W register
sets but here I'm really limited to 2R1W so I can't make an atomic instruction
that writes the carry bit to a different register address in the same cycle.
That stinking bit has to go somewhere, and it must be switch-safe :-/

I don't know if it's clearer.
If not, you can check some details on yasep.org or ask me.

Thank you for your time,
yg
-- 
http://ygdes.com / http://yasep.org

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

#1394

On May 8, 4:01 pm, whygee <y...@yg.yg> wrote:
> Hello,
>
> I hope that the old guard here can provide some wisdom and knowledge :-)
>
> In the context of a fixed-size instruction and byte-oriented computer architecture,
> such as ARMv7, MIPS, SPARC and so on, the Least Significant Bit of the instruction
> pointer is wasted and cleared.
>
> ARM Thumb uses it to define the current instruction set mode,
> which makes a lot of sense for them.


zSeries (the current incarnation of S/360) does something similar
with  the low bit and the high bit of a 32 bit bottom half of a
register.  All instructions are 2, 4 or 6 bytes long, and are aligned
on halfword (2 byte) boundaries.  Various combinations of those two
bits select between 24, 31 and 64 bit addressing.  Prior to XA mode
(circa ~1980), addressing was 24 bit.  XA extended that to 31 bits,
and used the high bit of the 32 bit registers to store (in some cases)
a mode indication, and then a special branch-with-mode-setting
instruction could switch from 24 to 31 bit mode or vice versa, which
made calling between 24 and 31 code reasonably straight-forward.  With
the introduction of 64 bit mode (circa 2000), the low bit of the
addresses were used to select between 64 bit mode and the 24/31 bit
modes.

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

#1396

Hello,

robertwessel2@yahoo.com wrote:
> zSeries (the current incarnation of S/360) does something similar
> with  the low bit and the high bit of a 32 bit bottom half of a
> register.  All instructions are 2, 4 or 6 bytes long, and are aligned
> on halfword (2 byte) boundaries.  Various combinations of those two
> bits select between 24, 31 and 64 bit addressing.  Prior to XA mode
> (circa ~1980), addressing was 24 bit.  XA extended that to 31 bits,
> and used the high bit of the 32 bit registers to store (in some cases)
> a mode indication, and then a special branch-with-mode-setting
> instruction could switch from 24 to 31 bit mode or vice versa, which
> made calling between 24 and 31 code reasonably straight-forward.  With
> the introduction of 64 bit mode (circa 2000), the low bit of the
> addresses were used to select between 64 bit mode and the 24/31 bit
> modes.

Wow...

I try to avoid that kind of "mode bit craze" for many reasons,
and I design the YASEP in such a way that if the architecture
is not powerful enough, one is compelled to use another one, better
suited to the task (a big brother of the YASEP could appear one day).

It is possible today because software is comparatively less
expensive than on IBM systems : it's easier to recompile or
reassemble for a new target, while IBM (and customers) has (had)
so much precious hand-written "legacy" code... In a GNU world,
that makes less sense.

In the early iterations of the YASEP architecture, I played
with the idea of using the MSB of the addresses but that made
many things more complex rather than simplify coding and implementation.

Any more examples of architectures playing with the LSB and MSB ?

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

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

#1400

On May 9, 1:02 am, whygee <y...@yg.yg> wrote:

> Wow...
>
> I try to avoid that kind of "mode bit craze" for many reasons,

Yes, but as you note, this was done because of the urgent need to
preserve absolute backwards compatibility. Even today, the x86
architecture still has that issue, because people do want to just run
their old software - which is commercially purchased, so it's not as
if they could compile it for a new target..

John Savard

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

#1399

On May 9, 1:58 am, "robertwess...@yahoo.com" <robertwess...@yahoo.com>
wrote:
> On May 8, 4:01 pm, whygee <y...@yg.yg> wrote:
>
> > Hello,
>
> > I hope that the old guard here can provide some wisdom and knowledge :-)
>
> > In the context of a fixed-size instruction and byte-oriented computer architecture,
> > such as ARMv7, MIPS, SPARC and so on, the Least Significant Bit of the instruction
> > pointer is wasted and cleared.
>
> > ARM Thumb uses it to define the current instruction set mode,
> > which makes a lot of sense for them.
>
> zSeries (the current incarnation of S/360) does something similar
> with  the low bit and the high bit of a 32 bit bottom half of a
> register.  All instructions are 2, 4 or 6 bytes long, and are aligned
> on halfword (2 byte) boundaries.  Various combinations of those two
> bits select between 24, 31 and 64 bit addressing.  Prior to XA mode
> (circa ~1980), addressing was 24 bit.

The 360/67 had 31-bit addressing mode--circa 1970.

>                                                        XA extended that to 31 bits,
> and used the high bit of the 32 bit registers to store (in some cases)
> a mode indication, and then a special branch-with-mode-setting
> instruction could switch from 24 to 31 bit mode or vice versa, which
> made calling between 24 and 31 code reasonably straight-forward.  With
> the introduction of 64 bit mode (circa 2000), the low bit of the
> addresses were used to select between 64 bit mode and the 24/31 bit
> modes.

Mitch

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

#1404

On May 9, 11:38 am, MitchAlsup <MitchAl...@aol.com> wrote:
> On May 9, 1:58 am, "robertwess...@yahoo.com" <robertwess...@yahoo.com>
> wrote:
>
>
>
>
>
> > On May 8, 4:01 pm, whygee <y...@yg.yg> wrote:
>
> > > Hello,
>
> > > I hope that the old guard here can provide some wisdom and knowledge :-)
>
> > > In the context of a fixed-size instruction and byte-oriented computer architecture,
> > > such as ARMv7, MIPS, SPARC and so on, the Least Significant Bit of the instruction
> > > pointer is wasted and cleared.
>
> > > ARM Thumb uses it to define the current instruction set mode,
> > > which makes a lot of sense for them.
>
> > zSeries (the current incarnation of S/360) does something similar
> > with  the low bit and the high bit of a 32 bit bottom half of a
> > register.  All instructions are 2, 4 or 6 bytes long, and are aligned
> > on halfword (2 byte) boundaries.  Various combinations of those two
> > bits select between 24, 31 and 64 bit addressing.  Prior to XA mode
> > (circa ~1980), addressing was 24 bit.
>
> The 360/67 had 31-bit addressing mode--circa 1970.


Actually the 360/67 had 32 bit addressing, and was rather out of the
mainstream when running in 32 bit mode* (which also included virtual
memory support, but not compatible with the S/370 implementation).


*as in, it wouldn't run your normal 24 bit programs in that mode.
While the OS could create both 24 and 32 bit address spaces, and the
24 bit address spaces continued to run as expected by the S/360 ISA,
communicating between 32 and 24 bit address spaces was clumsy, and you
couldn't really put both 24 and 32 bit code in a single address
space.  By contrast, 24, 31 and 64 bit code can all live in the same
address space in zArch, and calls between 24,31 and 64 bit calls are a
simple branch/call with mode setting (rather obviously if you want to
call 24 bit code from 64 bit code, you need to make sure the
parameters and whatnot are in 24 bit addressable storage).

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

#1407

MitchAlsup <MitchAlsup@aol.com> writes:
> The 360/67 had 31-bit addressing mode--circa 1970.

360/67 had 32bit addressing in 1967. 360/67 functional characteristics
at bitsavers:
http://www.bitsavers.org/pdf/ibm/360/funcChar/A27-2719-0_360-67_funcChar.pdf

it also had all processors able to address all channels in smp
configuration ... other 360&370 smp had dedicated io/channels ... more
than 24bit addressing and smp support for all processors accessing all
channels ... didn't re-appear until 1983 (370xa on 3081)

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

#1398

whygee <yg@yg.yg> writes:

> Hello,
>
> I hope that the old guard here can provide some wisdom and knowledge :-)
>
> In the context of a fixed-size instruction and byte-oriented computer architecture,
> such as ARMv7, MIPS, SPARC and so on, the Least Significant Bit of the instruction
> pointer is wasted and cleared.
>
> ARM Thumb uses it to define the current instruction set mode,
> which makes a lot of sense for them.
>
> So can people here tell me what other uses of this LSB have
> been tried in the past ?


Early ARM processors used the last two bits of the PC to store the
processor mode.  This was long before Thumb, so the modes were user,
supervisor, interrupt and fast interrupt.  The same ARMs also used the
top four bits of the PC to store arithemtic flags.  This had the
advantage that you could store both PC and flags using a single word,
but it limited the PC to a 256 MB range.  Later ARM designs moved both
flags and processor status to a separate (unnumbered) register and later
still Thumb used the lsb to indicate 16/32-bit mode.

If you want to use the lsb for something, I suggest it is for something
that is useful to change and/or preserve across jumps or calls, as you
can change/save it along with the PC.

	Torben

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

#1401

Torben Ægidius Mogensen wrote:
> Early ARM processors used the last two bits of the PC to store the
> processor mode.  This was long before Thumb, so the modes were user,
> supervisor, interrupt and fast interrupt.  The same ARMs also used the
> top four bits of the PC to store arithemtic flags.  This had the
> advantage that you could store both PC and flags using a single word,
> but it limited the PC to a 256 MB range.  Later ARM designs moved both
> flags and processor status to a separate (unnumbered) register and later
> still Thumb used the lsb to indicate 16/32-bit mode.

Interesting evolution, I didn't find this information in the recent manuals.
thanks !

> If you want to use the lsb for something, I suggest it is for something
> that is useful to change and/or preserve across jumps or calls, as you
> can change/save it along with the PC.

Yes, that's what worries me... But what to use it for ?

{{ 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 }}

After the recent posts in this thread, I have come up with these modifications :

  - the NIP has his LSB always cleared when read on the register read buses by instructions.
      This eases PC-relative computations, such as when I want to access a data byte
      relative to the current instruction, without having to flush the damn LSB
      (which would take 4 more bytes of code and a temp. reg.)

  - I just realised that the Carry bit is NOT used by the instructions as data
      on the register read bus, but only as part of the condition logic.
      That is why I have no need to keep the carry bit coupled to the NIP on the data bus,
      it will be coupled only during save/restore of the state. This directly
      addresses Kym's

However I turn this problem, I don't see yet what "mode" bit could/should be stored
and preserved through calls/returns. There will be enough resources and features
to address most needs in a rather clean way, such as inter-thread calls (that
changes the execution context but not the registers) for inter-mode operation,
including 16-to-32 bits code communication or eventual instruction set "modes".

{{ Now I'm even more curious : has anyone ever used the LSB for breakpoints ? }}

> 	Torben
yg

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

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

#1402

You could use the PC's lsb as the interrupt enable.

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

#1406

Hi !

mac wrote:
> You could use the PC's lsb as the interrupt enable.

it's been done already (see ARM) and no, IRQ in YASEP
are handled somewhere else. Plus there is the risk
of accidentally disabling IRQ (address computing bug
or whatever malevolent program)

IRQ masking is performed at the program level
by the CRIT instruction which "opens" a predetermined
lenght critical section of up to 16 consecutive instructions.

http://yasep.org/ISM/CRIT.html

Yes, i know, it adds a tiny 4-bit counter but i can handle
this little overhead since it seems to be a good compromise.
There are (will be) IRQ enable bits in the IRQ controller
and no potentially dangerous way for an application to
disrupt the system, yet they can have little moments of
privacy :-)

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

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

#1414

whygee  <yg@yg.yg> wrote:
+---------------
| mac wrote:
| > You could use the PC's lsb as the interrupt enable.
| 
| it's been done already (see ARM) and no, IRQ in YASEP
| are handled somewhere else. Plus there is the risk
| of accidentally disabling IRQ (address computing bug
| or whatever malevolent program)
| 
| IRQ masking is performed at the program level
| by the CRIT instruction which "opens" a predetermined
| lenght critical section of up to 16 consecutive instructions.
| 
| http://yasep.org/ISM/CRIT.html
| 
| Yes, i know, it adds a tiny 4-bit counter ...
+---------------

Heh, heh! Indeed, it *has* been done already!! See the DCA[1]
"SmartMux/3xx" series terminal networking switches circa 1972(!),
which included *precisely* this functionality as an add-on
to the PDP-8/e instruction set!! Yes, with a 4-bit counter.  ;-}


-Rob

[1] B.t.w., that's "Digital Communications Associates" in Atlanta, GA,
    not the U.S. military agency that formerly had the same acronym.

-----
Rob Warnock		<rpw3@rpw3.org>
627 26th Avenue		<http://rpw3.org/>
San Mateo, CA 94403

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

#1415

Rob Warnock wrote:
> Heh, heh! Indeed, it *has* been done already!! See the DCA[1]
> "SmartMux/3xx" series terminal networking switches circa 1972(!),
> which included *precisely* this functionality as an add-on
> to the PDP-8/e instruction set!! Yes, with a 4-bit counter.  ;-}

Damnit !
Yet another proof that there is nothing left to invent :-D
Most guy would think "oh crap, i'm not as smart as i wanted to
believe", I think "oh great, nobody will harass me with bogus
patents" :-P

thanks for the hint !!!
Yet another proof that this group rocks :-)

> -Rob
YG
-- 
http://ygdes.com / http://yasep.org

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

#1465

On 5/9/2011 6:23 PM, Rob Warnock wrote:
> whygee<yg@yg.yg>  wrote:
> +---------------
> | mac wrote:
> |>  You could use the PC's lsb as the interrupt enable.
> |
> | it's been done already (see ARM) and no, IRQ in YASEP
> | are handled somewhere else. Plus there is the risk
> | of accidentally disabling IRQ (address computing bug
> | or whatever malevolent program)
> |
> | IRQ masking is performed at the program level
> | by the CRIT instruction which "opens" a predetermined
> | lenght critical section of up to 16 consecutive instructions.
> |
> | http://yasep.org/ISM/CRIT.html
> |
> | Yes, i know, it adds a tiny 4-bit counter ...
> +---------------
>
> Heh, heh! Indeed, it *has* been done already!! See the DCA[1]
> "SmartMux/3xx" series terminal networking switches circa 1972(!),
> which included *precisely* this functionality as an add-on
> to the PDP-8/e instruction set!! Yes, with a 4-bit counter.  ;-}

Intel i860 did something similiar.

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

#1474

Hi Andy !

Andy "Krazy" Glew wrote:
> On 5/9/2011 6:23 PM, Rob Warnock wrote:
>> whygee<yg@yg.yg>  wrote:
>> +---------------
>> <snip>
>> | IRQ masking is performed at the program level
>> | by the CRIT instruction which "opens" a predetermined
>> | lenght critical section of up to 16 consecutive instructions.
>> |
>> | http://yasep.org/ISM/CRIT.html
>> |
>> | Yes, i know, it adds a tiny 4-bit counter ...
>> +---------------
>>
>> Heh, heh! Indeed, it *has* been done already!! See the DCA[1]
>> "SmartMux/3xx" series terminal networking switches circa 1972(!),
>> which included *precisely* this functionality as an add-on
>> to the PDP-8/e instruction set!! Yes, with a 4-bit counter.  ;-}
> 
> Intel i860 did something similiar.

I can't locate a PDF of this architecture.
Unless it's behind a paywall :-/

However I found this :
http://ibmmuseum.com/ohlandl/CPU/wizard.html

"* Bus lock/unlock instructions for flexible indivisible
  read-modify-write sequences.  Interrupts are disabled
  while the bus is locked.  "If ... the processor does
  not encounter a load or store following an unlock
  instruction by the time it has executed 32 instructions,
  it triggers an instruction fault...".
   For example: locked test and set is:
// r22 <- semaphore, semaphore <- r23
lock                // next cache miss load/store locks bus
ld.b    semaphore, r22
unlock             // next load/store unlocks bus
st.b    r23, semaphore
"

Is this what you are refering to ?

It's funny because when i defined the "CRIT" instruction,
it remembered me of the "load/store locked" instructions
of MIPS (eventually Alpha ?) but i wanted to do something
more generic/general. And safe. That's why I define how
many instructions are critical, instead of defining a couple
of instructions (like the lock/unlock above).

What's interesting in the MIPS flavor is that (IIRC) there
is a status bit that is updated so the SW knows if the
sequence was interrupted so it can rerun it. Here, the
"critical" sequence is not meant to be interrupted (unless
it traps because of a fault, too bad) so no need to get
the status.

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

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

#1523

On 5/11/2011 5:45 PM, whygee wrote:
> Hi Andy !
>
> Andy "Krazy" Glew wrote:
>> On 5/9/2011 6:23 PM, Rob Warnock wrote:
>>> whygee<yg@yg.yg> wrote:
>>> +---------------
>>> <snip>
>>> | IRQ masking is performed at the program level
>>> | by the CRIT instruction which "opens" a predetermined
>>> | lenght critical section of up to 16 consecutive instructions.
>>> |
>>> | http://yasep.org/ISM/CRIT.html
>>> |
>>> | Yes, i know, it adds a tiny 4-bit counter ...
>>> +---------------
>>>
>>> Heh, heh! Indeed, it *has* been done already!! See the DCA[1]
>>> "SmartMux/3xx" series terminal networking switches circa 1972(!),
>>> which included *precisely* this functionality as an add-on
>>> to the PDP-8/e instruction set!! Yes, with a 4-bit counter. ;-}
>>
>> Intel i860 did something similiar.
>
> I can't locate a PDF of this architecture.
> Unless it's behind a paywall :-/

It predates the web.

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.



> However I found this :
> http://ibmmuseum.com/ohlandl/CPU/wizard.html
>
> "* Bus lock/unlock instructions for flexible indivisible
> read-modify-write sequences. Interrupts are disabled
> while the bus is locked. "If ... the processor does
> not encounter a load or store following an unlock
> instruction by the time it has executed 32 instructions,
> it triggers an instruction fault...".
> For example: locked test and set is:
> // r22 <- semaphore, semaphore <- r23
> lock // next cache miss load/store locks bus
> ld.b semaphore, r22
> unlock // next load/store unlocks bus
> st.b r23, semaphore
> "
>
> Is this what you are refering to ?

My MS thesis describes it briefly (part of my MS thesis was a survey of 
all synchronization techniques current in 1990).  Hmm...  I don't think 
my MS thesis is on the web, either.  I have it on tape somewhere...

IIRC, the i860 LOCK instruction made the processor uninterruptible and 
asserted a LOCK# pin on the bus for 32 cycles.  So, if you could do your 
atomic operation in 32 cycles or less...  It was actually more flexible 
than LL/SC in this regard, although a later rev rediced what you were 
allowed to do in the locked 32 cycles.


> It's funny because when i defined the "CRIT" instruction,
> it remembered me of the "load/store locked" instructions
> of MIPS (eventually Alpha ?) but i wanted to do something
> more generic/general. And safe. That's why I define how
> many instructions are critical, instead of defining a couple
> of instructions (like the lock/unlock above).
>
> What's interesting in the MIPS flavor is that (IIRC) there
> is a status bit that is updated so the SW knows if the
> sequence was interrupted so it can rerun it. Here, the
> "critical" sequence is not meant to be interrupted (unless
> it traps because of a fault, too bad) so no need to get
> the status.
>
> yg

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

#1585

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

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

#1590

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.

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch

csiph-web