Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Wed, 04 Apr 2012 18:11:14 -0500 Message-ID: <4F7CD50E.1090503@SPAM.comp-arch.net> Date: Wed, 04 Apr 2012 16:11:10 -0700 From: "Andy (Super) Glew" Reply-To: andy@SPAM.comp-arch.net Organization: comp-arch.net User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 Newsgroups: comp.arch Subject: Re: M68k add to memory is not a mistake any more References: <9thhmnFdvbU1@mid.individual.net> <3c05c00c-c54f-4ce3-bc2f-a66293740d10@ms3g2000pbb.googlegroups.com> <4F7B9B0F.6060906@SPAM.comp-arch.net> <213fff09-87c5-4c62-8e25-8c8da4b0fe00@vy8g2000pbc.googlegroups.com> <4F7CC9AF.8080805@SPAM.comp-arch.net> In-Reply-To: <4F7CC9AF.8080805@SPAM.comp-arch.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 54 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-ibthjnSom6YzVRJzp0hzA5r8haXcM99uDgmObVMqBXcp7zXsoKCA6J1tBZ6WOkcg38jY287WS2YU6o0!/5fwTArnrS6wjPdPVdPy4ESJ6jAcnqcjnY9Wo0G0TufbbvwJ5MGfE/1dFGgw X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 3708 Xref: csiph.com comp.arch:6447 On 4/4/2012 3:22 PM, Andy (Super) Glew wrote: > On 4/4/2012 1:54 PM, Quadibloc wrote: >> On Apr 3, 6:51 pm, "Andy (Super) Glew" >> wrote: >> >>> I am a big advocate of there being defined code sequences that will save >>> and restore all state. Even state that did not exist at the time the >>> interrupt handler was written. >> >> That is a good idea. Except for one thing. Since one isn't talking >> about the fast but not scalable situation of a shadow state that you >> noted, this saved state is going into _memory_. >> >> However, this is not an insuperable problem. If the machine has *a >> stack*, then the fact that the amount of the stack that will be used >> is _not defined_ in the description of the instruction won't prevent >> the instruction from being usable. >> >> Absent a stack, code that stores machine state in successive 256-byte >> regions after the architecture has been extended to have 512 bytes of >> state will fail just as surely as code that fails to save a new part >> of the state. >> >> John Savard > > Notice that I did not say "a single instruction that saves/restes all > state". Notice that I said 'a code sequence'. > > I'm just as happy if SW has to read a CPUID register to find out how > much state there is. So that SW can allocate howsoever it wants. Or if > software has to access this state N bits at a time, using a generic > READ_STATE instruction. > > I'm not happy if you have to use a new instruction to access new state, > especially if that instruction did not exist on old machines. I'm okay > if generic software an figure out that it has to use a new instruction. > > I'm not a fan of hardwiring a stack into the ISA. > And what I really don't like are control register architectures that have really funky dependencies, e.g. First you have to set CRxxx to F00 then write CRyyy to BAA then set CRxxx to B122 then set CRyyy to B1F unless SRzzz contains 8 in which case you must... If there are such dependencies in legacy architecture, document. And try to avoid.