Groups | Search | Server Info | Login | Register
| From | MitchAlsup <MitchAlsup@aol.com> |
|---|---|
| Newsgroups | comp.arch |
| Subject | Re: Architecting a return address stack |
| Date | 2012-04-05 09:08 -0700 |
| Organization | http://groups.google.com |
| Message-ID | <7282732.580.1333642090699.JavaMail.geo-discussion-forums@ynkh5> (permalink) |
| References | <37e7fa2b-2d98-428d-bdb8-369b995bcaad@d17g2000vba.googlegroups.com> <3547937.746.1332950262513.JavaMail.geo-discussion-forums@ynjx8> <29266476.18.1333566235966.JavaMail.geo-discussion-forums@ynll3> |
On Wednesday, April 4, 2012 2:03:55 PM UTC-5, gg...@yahoo.com wrote: > On Wednesday, March 28, 2012 10:57:42 AM UTC-5, MitchAlsup wrote: > > Do yourself (and everyone else) a favor and don't. > > > > That is, let the stack, which is an inherently software feature, be defined in a way that best fits the needs of the software, by those who have to maintain the software. > > So you prefer the Alpha approach of the LINK register being a normal register, > as opposed to the more typical special register that is mostly hidden? > > You can throw some special hardware at LINK, but I think most just use a register. > Is the idea of throwing extra hardware at LINK just futile duplication? For the extremely restircted branch-to-subroutine instruction, I accept the necessity to have a predefined place (register) to put the return address. For the similar jump-to-subroutine instruction, the instruction can provide the register bits needed. Whether the JSR does or not is at the architects discresssion. What I was saying back to Paul was that the hardware should not define what stacks are (place, register, movement direction) as this should be (and can be) completely defined, and implemented in software. This bypasses the subtle bugs that one might get if one defines push and pop instructions with various operand sizes that come up when the stack pointer gets misaligned wrt the next item to be pushed or popped. Software can work around these issues a lot easier than hardware can. It also avoids issues when the base architecture changes size (from 32-bits to 64-bits: for example). Mitch
Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar
Architecting a return address stack "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-03-27 17:35 -0700
Re: Architecting a return address stack MitchAlsup <MitchAlsup@aol.com> - 2012-03-28 08:57 -0700
Re: Architecting a return address stack ggtgp@yahoo.com - 2012-04-04 12:03 -0700
Re: Architecting a return address stack MitchAlsup <MitchAlsup@aol.com> - 2012-04-05 09:08 -0700
Re: Architecting a return address stack torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-04-10 12:23 +0200
Re: Architecting a return address stack Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-10 22:22 +0200
Re: Architecting a return address stack torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-04-12 09:52 +0200
Re: Architecting a return address stack jacko <jackokring@gmail.com> - 2012-04-14 08:32 -0700
csiph-web