On Tuesday, February 19, 2013 08:01:30, Adam wrote: > Chris Knadle wrote: > > On Saturday, February 16, 2013 14:56:33, Adam wrote: > > In the case you mention for BAL (S/360/370/390 assembly), I'm > > guessing that there was no CPU instruction available for PUSH and > > > > POP > > Yep, at least none I knew of. A consequence of this is that it also > didn't have "call subroutine" and "return from subroutine" instructions > which would save and retrieve the IP from the stack.
Wow. Okay yeah I understand. > > and that the way you "faked" it was via indirect memory > > addressing and updating a "variable" (a memory location) to contain > > > > the current "pointer" into the indirect-addressed memory. > > Exactly. I also had to remember to have the recursive subroutine store > its local variables on the "stack", instead of the equivalent of DEFB, > DEFW, etc. "Define Byte", "Define Word" -- yeah I see. Pre-compile directives to assign a memory location to a variable. > > Recursion is usually limited to certain kinds of jobs that naturally > > lend themselves to recursive solutions. > > Usually, yes, although I once heard someone (may have been my Pascal > instructor) say something like "Anything that can be done with nested > loops can be done with recursion". (I'm not sure I got that right!) Sounds right to me. > > For instance -- solving an > > NxN matrix determinant -- that's something that lends itself to a > > > > recursive solution, because any NxN matrix determinant can be broken > > down into 2x2 determinants. [This is a fun exercise.] > > That sounds familiar -- I /might/ have done that in high school using APL. I've never seen this given as an assignment. When I did it, I had been given an assignment to write a "normal" C program to calculate the determinant of a 3x3 matrix, and they gave us the "formula" for doing it. That seemed really boring, and I had a calculator that would give me the answer for the determinant of an NxN matrix, but I had no idea how it worked. ;-) > > To try to deal with the heat issue, voltages that the processors use > > have been incrementally lowered. Many CPUs these days run on ~1.25v. > > (I think this is considered LVCMOS.) This gets into limitations on > > the voltage thresholds for what a "1" and a "0" are. > > > >> That 0.7v drop? > > > > More like 0.2v - 0.5v these days, but yes. > > What materials are they using for those? https://en.wikipedia.org/wiki/Metal_oxide_semiconductor_field_effect_transistor > > The actual "results" you get from different CPUs differs depending on > > > > the architecture though. There have been various tricks used over > > the years to get more out of the CPU without increasing the clock > > rate. Instruction sets (CISC vs RISC), instruction pre-fetching and > > branch anticipation, pipelining, etc. > > Sounds like Moore's Law is going to be less applicable, though, as the > rate of increase of processing speed comes closer to some absolute limit. Depends. Things may change when they come out with graphite-based transistors. I imagine that's going to present another manufacturing challenge though. -- Chris -- Chris Knadle [email protected] _______________________________________________ Mid-Hudson Valley Linux Users Group http://mhvlug.org http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug Upcoming Meetings (6pm - 8pm) Vassar College Feb 6 - Raspberry Pi Mar 6 - 10th Anniversary Meeting - Linux where you least expect it Apr 3 - Typography: Physical Art to Digital Art
