Re: Intel

Liste des GroupesRevenir à se design 
Sujet : Re: Intel
De : blockedofcourse (at) *nospam* foo.invalid (Don Y)
Groupes : sci.electronics.design
Date : 04. Aug 2024, 20:22:06
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v8okcv$6o40$1@dont-email.me>
References : 1 2 3 4 5 6 7
User-Agent : Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
On 8/4/2024 11:27 AM, Edward Rawde wrote:
Yes, the 1802 was great, the address bus was muxed high byte low bytes so
interfacing to DRAM was extremely easy.
 I never used the 1802 but it did look like a nice architecture to me at the time.
Is that the one which stored the return address in the first two addresses of a subroutine or am I thinking of something else?
The 1802 made the programmer "manually" alter the PC and, later, restore
it.
You essentially told the processor to use a different register
as the PC -- after having placed the address (registers are 16b)
in that register.  You similarly would re-alter it to get back to
the point (following) where you made the change.
[This is a cruder version of the more modern BAL -- where the
programmer specifies the link register]
There are a couple of different ways of doing this but none is really
as clean (or efficient) as a CALL/JSR/BAL.  You had to write code
to BUILD the CALL/JSR *mechanism* and then use that "subroutine"
as a linkage to invoke your desired "subroutine" while stacking the
return address so YOU could perform the reverse linkage when
the subroutine was complete.
I.e., think about what a "normal" processor does when it encounters
a CALL:
copy the address following the instruction onto a stack...
... that is indexed by a "stack pointer" register...
... updating that register in preparation for the next use...
place the destination address into the program counter
<your code here>
retrieve the stacked address "before" the referenced SP location...
...update the "stack pointer" register...
place the retrieved address into the program counter
Code for each of the above steps had to be WRITTEN by the programmer
to emulate a CALL (and RETURN) facility.
This was incredibly inefficient -- especially for a slow processor.
Newer processor designs avoid storing the return address on a
memory-based stack as this often causes needless memory accesses.
I.e., if your subroutine isn't going to "call" anything, then
why do you need to store more than the most recent return
address... IN A REGISTER!
[If you are going to need to call another subroutine, then you
take steps to preserve the state of any registers that could
be clobbered in that action -- like the "link" register!]

Date Sujet#  Auteur
3 Aug 24 * Intel43John Larkin
3 Aug 24 `* Re: Intel42Joe Gwinn
3 Aug 24  +* Re: Intel30John Larkin
3 Aug 24  i+* Re: Intel4Phil Hobbs
4 Aug 24  ii`* Re: Intel3Gerhard Hoffmann
4 Aug 24  ii `* Re: Intel2Dimiter_Popoff
5 Aug 24  ii  `- Re: Intel1Don Y
5 Aug 24  i`* Re: Intel25John Larkin
5 Aug 24  i `* Re: Intel24John Larkin
6 Aug 24  i  +* Re: Intel21Jan Panteltje
6 Aug 24  i  i+* Re: Intel17Bill Sloman
6 Aug 24  i  ii`* Re: Intel16Jan Panteltje
6 Aug 24  i  ii +* Re: Intel3John Larkin
7 Aug 24  i  ii i+- Re: Intel1Jan Panteltje
17 Aug 24  i  ii i`- Re: Intel1Bill Sloman
7 Aug 24  i  ii `* Re: Intel12Bill Sloman
7 Aug 24  i  ii  `* Re: Intel11Jan Panteltje
7 Aug 24  i  ii   `* Re: Intel10Bill Sloman
7 Aug 24  i  ii    `* Re: Intel9Jan Panteltje
7 Aug 24  i  ii     `* Re: Intel8Bill Sloman
7 Aug 24  i  ii      `* Re: Intel7Jan Panteltje
8 Aug 24  i  ii       `* Re: Intel6Bill Sloman
8 Aug 24  i  ii        `* Re: Intel5Jan Panteltje
10 Aug 24  i  ii         `* Re: Intel4Bill Sloman
12 Aug 24  i  ii          `* Re: Intel3brian
12 Aug 24  i  ii           `* Re: Intel2John Larkin
12 Aug 24  i  ii            `- Re: Intel1Phil Hobbs
6 Aug 24  i  i`* Re: Intel3John Larkin
7 Aug 24  i  i +- Re: Intel1Bill Sloman
7 Aug 24  i  i `- Re: Intel1Jan Panteltje
6 Aug 24  i  `* Re: Intel2bitrex
6 Aug 24  i   `- Re: Intel1John Larkin
4 Aug 24  `* Re: Intel11Don Y
4 Aug 24   `* Re: Intel10TTman
4 Aug 24    +* Re: Intel3John Larkin
4 Aug 24    i`* Re: Intel2Joe Gwinn
4 Aug 24    i `- Re: Intel1John Larkin
4 Aug 24    `* Re: Intel6Don Y
4 Aug 24     `* Re: Intel5piglet
4 Aug 24      +- Re: Intel1Don Y
4 Aug 24      `* Re: Intel3Edward Rawde
4 Aug 24       +- Re: Intel1John Larkin
4 Aug 24       `- Re: Intel1Don Y

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal