13 Dec
2001
13 Dec
'01
5:27 a.m.
Hi,
I found this really interesting: The PDP-8 has no concept of a
stack. It does have sub-routines though. Instead of pushing the
instruction pointer onto a stack, it's being written at the
location to which the call is directed (first address of the
subroutine). Then a return is simply an indirect jump to that
first address of the subroutine.
This is hillarious! Wasn't the notion of a stack arond already
before 1965?
The coolest thing is that inspite of this "unique" way of handling
subroutines, the PDP-8 had a timesharing system TSS-8. I suppose
they could not share code segments then, so if three users were
doing FOCAL, they would have 3 instances of the FOCAL code in
memory (or swapping in and out to disk.) And all this at maximally
32 kB of memory! Amazing.
I just wonder how the kernel calls were handled. The kernel was
called "Monitor." That may be the revealing piece of it: perhaps
the Monitor was a monitor, so only one thread could ever execute
any of the monitor's code at the same time.
That raises a last question: what was first, the TSS-8 kernel
called "Monitor" or the operating system technical term "monitor"?
Dijkstra's classic semaphore paper was back in 1968, and my "new"
Introduction to Programming book is printed 1968 too. AFAIK
the monitor construct is younger than the semaphore, right? So,
could it be that the technical term "monitor" comes from taking the
functioning of the TSS-8 kernel as a paradigma?
fun stuff, isn't it?
-Gunther
PS: I think one could emulate something like a stack on the
PDP-8 using the auto-increment registers in the PDP-8's zero
page. Of course it would work without them, but it may make
the one of the operations push or pop more efficient...
--
Gunther Schadow, M.D., Ph.D. gschadow(a)regenstrief.org
Medical Information Scientist Regenstrief Institute for Health Care
Adjunct Assistant Professor Indiana University School of Medicine
tel:1(317)630-7960 http://aurora.regenstrief.org
12 Dec
12 Dec
9:51 p.m.
Gunther wrote:
I found this really interesting: The PDP-8 has no
concept of a
stack. It does have sub-routines though. Instead of pushing the
instruction pointer onto a stack, it's being written at the
location to which the call is directed (first address of the
subroutine). Then a return is simply an indirect jump to that
first address of the subroutine.
This is hillarious! Wasn't the notion of a stack arond already
before 1965?
Interesting... I suppose that it had to do with the fact
that the pdp8 was supposed to be affordable...
Roughly 13 years later, the RCA 1802 was introduced; it doesn't
have a fully functional stack either, and in order to call a
subroutine located far away you have to do stack manipulation
yourself, resulting in an 8 or so instruction sequence before
calling and a similar one to return. I hated it because I
was already used to the 8085.
Then, there was the hp 3000 architecture (ca. 1973), which relied
on the stack hardware at all levels.
carlos.
T
1:45 p.m.
cmurillo(a)multi.net.co wrote:
Gunther wrote:
I can think of two other good
reasons that a stack was not
found on a PDP-8. First is was based on the PDP-5 a digital
controller , not a general computer. Second there is no room
for stack instructions in the order code with only a 12 bit
word width. Having a hardware JSR has a real feature of
the instruction set.
A a side note stack based programs are harder to recover from
when a stack blows up.
BTW If you really need a 12/24 bit processor with stacks,
I have a nice design. A nice cpu but only 1 in existence
still :)
Ben Franchuk --- Pre-historic Cpu's --
www.jetnet.ab.ca/users/bfranchuk/index.html
I found this really interesting: The PDP-8 has no
concept of a
stack. It does have sub-routines though. Instead of pushing the
instruction pointer onto a stack, it's being written at the
location to which the call is directed (first address of the
subroutine). Then a return is simply an indirect jump to that
first address of the subroutine.
This is hillarious! Wasn't the notion of a stack arond already
before 1965?
Interesting... I suppose that it had to do with the fact
that the pdp8 was supposed to be affordable... 
13 Dec
13 Dec
6:26 a.m.
New subject: [PDP8-Lovers] if you hadn't already known this about the PDP-8
On Thu, 13 Dec 2001 11:27:26 -0500, Gunther Schadow wrote:
The PDP-8 has no concept of a
stack.
This is hillarious! Wasn't the notion of a stack arond already
before 1965?
So was a machine instruction to do multiply, but on a PDP-8 that is an add-on
hardware option
this "unique" way of handling
subroutines
Unique? Quite a few processors of that time had a store-PC-and-jump type of
subroutine call. The beloved PDP-10 had three (JSR, JSP, JSA/JRA) and
subsequent enhancements added more (JSYS, XPCW); yet it also had stacks from
its inception.
Contemporary programming languages, such as BASIC and FORTRAN, did not use
stack subroutines. It's possible that modern BASIC and FORTRAN compilers may
permit recursive subroutine calls, but doing so is still prohibited by the
language specification. Now you know why.
Stacks are very useful, but they are not the solution to everything. One of
the biggest deficiencies of C is its lack of co-routines, since it only has
the stack style of subroutine calling. Yeah, I know about setjmp/longjmp, but
those are one-way, not true co-routines.
Of course, talking about co-routines to youngsters is likely to get their eyes
to glaze over, since they won't have a clue as to what I'm talking about.
I suppose
they could not share code segments then, so if three users were
doing FOCAL, they would have 3 instances of the FOCAL code in
memory (or swapping in and out to disk.) And all this at maximally
32 kB of memory! Amazing.
The concept of shared memory appeared quite some time (late 1960s) after the
PDP-8 architecture was designed, and at first only carefully-designed programs
could use it.
I just wonder how the kernel calls were handled. The
kernel was
called "Monitor." That may be the revealing piece of it: perhaps
the Monitor was a monitor, so only one thread could ever execute
any of the monitor's code at the same time.
Non-sequitor. AFAIK, the PDP-8 operating system used invalid (in user mode)
instructions as system calls, and these were generally the same as the machine
instructions that would do the equivalent operation. Since this is an
instruction trap, it doesn't subroutine calls.
I certainly would never design an operating system that uses the user's stack
to invoke a system call.
That raises a last question: what was first, the TSS-8
kernel
called "Monitor" or the operating system technical term "monitor"?
Because nobody used the word "kernel" back then. The term "monitor"
is far
older than Dijkstra's paper.
Dijkstra's classic semaphore paper was back in
1968, and my "new"
Introduction to Programming book is printed 1968 too. AFAIK
the monitor construct is younger than the semaphore, right?
No. The term appears in the early 1960s.
3:47 p.m.
New subject: [PDP8-Lovers] if you hadn't already known this about the PDP-8
It was thus said that the Great Mark Crispin once stated:
Contemporary programming languages, such as BASIC and FORTRAN, did not use
stack subroutines. It's possible that modern BASIC and FORTRAN compilers may
permit recursive subroutine calls, but doing so is still prohibited by the
language specification. Now you know why.
Stacks are very useful, but they are not the solution to everything. One of
the biggest deficiencies of C is its lack of co-routines, since it only has
the stack style of subroutine calling. Yeah, I know about setjmp/longjmp, but
those are one-way, not true co-routines.
Of course, talking about co-routines to youngsters is likely to get their eyes
to glaze over, since they won't have a clue as to what I'm talking about.
So what, exactly is a co-routine? I've heard the term before, but I'm not
entirely sure what they are, or how they would work.
-spc (I may have used them in assembly, but not knew the proper term ... )
6:46 a.m.
Gunther Schadow wrote:
I found this really interesting: The PDP-8 has no
concept of a
stack. It does have sub-routines though.
This is pretty characteristic of machines of the time. The Nova
didn't grow a stack until the mid-70's, although the call linkage
was somewhat different with the return address being hammered into
AC3 rather than written to memory (although the interrupt return
address did get written to location zero).
This is hillarious! Wasn't the notion of a stack
arond already
before 1965?
Of course. In machines frequently an order of magnitude
(if not even more) greater in cost.
The coolest thing is that inspite of this
"unique" way of handling
subroutines, the PDP-8 had a timesharing system TSS-8.
The lack of hardware support for a stack abstraction hardly precludes
the construction of shared or reentrant code. So you have to
manipulate the stack yourself rather than the hardware doing it
for you. Big deal; for many people the options in the late 1960s
were to do that or not have a machine at all. The big problem
is doing useful things in the absence of a memory mapping and
protection unit of some sort (the Nova grew one early on, but
I'm too ignorant of the PDP-8 family to know if such an option ever
existed).
--
Chris Kennedy
chris(a)mainecoon.com
http://www.mainecoon.com
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
10:03 a.m.
Perhaps today when you can pack arbitrarily large amounts of
hardware on a chip, memory is (practically) free, we (mostly) all
have internet connections, disks are gigantic, and computer
systems are cheap (er, inexpensive), it's hard to understand the
pdp-8 and contemporary computers... ;-)
Gunther Schadow wrote:
I found this really interesting: The PDP-8 has no
concept of a
stack. It does have sub-routines though. Instead of pushing the
instruction pointer onto a stack, it's being written at the
location to which the call is directed (first address of the
subroutine). Then a return is simply an indirect jump to that
first address of the subroutine.
Actually, most machines from this era used this method or something
like it... The CDC6000s actually stored a branch to the return
address in the first word of the subroutine.
You can, of course, implement stacked subroutine calls in
a pdp-8... This sort of thing was generally left as an exercise
to the student (I was one of those around that time... :-)
As an interesting side note, from my understanding, the MIPS
processor doesn't have a stack in the same way as the pdp-8
doesn't -- it has to be implemented "by hand", with stores
through a register (stack pointer) with the register incremented
or decremented... Of course, the MIPS has registers (note the
plural), while the pdp-8 has an accumulator.
This is hillarious! Wasn't the notion of a stack
arond already
before 1965?
Sure, the notion was around, look in Fundamental Algorithms
(Knuth,1968, a reference I still have on my desk...)
Stacks were mostly implemented in FORTRAN arrays, along
with linked lists and other "modern" data structures... :-)
I guess, after spending so much time programming those things, I had
missed the "hilarious" aspect of it... :-)
The coolest thing is that inspite of this
"unique" way of handling
subroutines, the PDP-8 had a timesharing system TSS-8. I suppose
they could not share code segments then, so if three users were
doing FOCAL, they would have 3 instances of the FOCAL code in
memory (or swapping in and out to disk.) And all this at maximally
32 kB of memory! Amazing.
Oh, and look at all the other suffering! Those three "users" on asr33
teletypes running at 110 baud, saving their programs on paper tape,
reading those programs through the reader on the tty, and splicing
the tape! The hours spent playing games like lunar lander, with its
wonderful tty graphics! A huge program was a box of cards (2000
as I remember... :-)
And the -- oh, oh, sorry, pardon the nostalgia trip... <grin>
In a sense, the hp2000c timesharing system did have "shared code
segments", in the sense that the whole time sharing system was a
basic interpreter with a file system/command processor tacked on,
so all the users (32 max, as I recall, it you has both multiplexors
in the 2114 communications processor...) shared the same "code".
The user area was swapped...
I just wonder how the kernel calls were handled. The
kernel was
called "Monitor." That may be the revealing piece of it: perhaps
the Monitor was a monitor, so only one thread could ever execute
any of the monitor's code at the same time.
Kernel?!!? We don't need no stinking kernel!
Real programmers read and write directly to the devices!
(Or just use the switch register!)
Operating system, Bah, Humbug! :-)
That raises a last question: what was first, the TSS-8
kernel
called "Monitor" or the operating system technical term "monitor"?
Dijkstra's classic semaphore paper was back in 1968, and my "new"
Introduction to Programming book is printed 1968 too. AFAIK
the monitor construct is younger than the semaphore, right? So,
could it be that the technical term "monitor" comes from taking the
functioning of the TSS-8 kernel as a paradigma?
The 7090 and 7094 at MIT in 1963 were controlled by the FORTRAN
Monitor System ( http://www.multicians.org/thvv/7094.html ), so the use
of monitor as this type of term goes back at least that far... The first ref
that I found to semaphores is Dijkstra in 1968, but it seems to me that the
term was in use before that...
(Other than in connection with signal flags and railroad signals, etc.
And monitors? heavily armored gunboats around Civil War time,
I believe... Named after the prototype...)
fun stuff, isn't it?
-Gunther
I would have to echo the comment by Fredrick P. Brooks, Jr., from
the Epilogue of the new revision of his classic book,
"The Mythical Man-Month":
"To only a fraction of the whole human race does God give the privilege
of earning one's bread doing what one would have gladly pursued for
free, for passion. I am very thankful." (Page 291)
After doing this for nearly thirty years, I still can't believe I'm getting
_paid_ to do this. Yes, I'd have to say it is fun, both looking back
and in the larger sense...
PS: I think one could emulate something like a stack
on the
PDP-8 using the auto-increment registers in the PDP-8's zero
page. Of course it would work without them, but it may make
the one of the operations push or pop more efficient...
--
Gunther Schadow, M.D., Ph.D. gschadow(a)regenstrief.org
Medical Information Scientist Regenstrief Institute for Health Care
Adjunct Assistant Professor Indiana University School of Medicine
tel:1(317)630-7960 http://aurora.regenstrief.org
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
12 Dec
12 Dec
1:14 p.m.
Bill McDermith wrote:
Perhaps today when you can pack arbitrarily large amounts of
hardware on a chip, memory is (practically) free, we (mostly) all
have internet connections, disks are gigantic, and computer
systems are cheap (er, inexpensive), it's hard to understand the
pdp-8 and contemporary computers... ;-)
But I ask the question is bigger always better? I am the guy who still
uses 640x480 cause this way he can read the screen and the menus at
the same time. I suspect the wheel of computer design will turn again
towards 'smaller' CISC (pdp8-style?) machines as the interconnect
in chips between modules is becoming larger compared to the the gate
speeds.
--
Ben Franchuk --- Pre-historic Cpu's --
www.jetnet.ab.ca/users/bfranchuk/index.html
13 Dec
13 Dec
11 a.m.
Bill McDermith
Perhaps today when you can pack arbitrarily large amounts of
hardware on a chip, memory is (practically) free, we (mostly) all
have internet connections, disks are gigantic, and computer
systems are cheap (er, inexpensive), it's hard to understand the
pdp-8 and contemporary computers... ;-)
This is something I get hit with on a daily basis. On the one hand I need
to have better than 64M for Windows!?! But my PIC projects barely need the
1024 bytes of ROM/128 bytes of RAM. I often wonder if 16M of RAM will be
enough for my VAX to run. Then I realize that it's not a Windows machine
and I'm happy again. :-)
One of these days I'll get a chance to get my VAX's up and running!
--
Linux Home Automation Neil Cherry ncherry(a)home.net
http://members.home.net/ncherry (Text only)
http://linuxha.sourceforge.net/ (SourceForge)
http://hcs.sourceforge.net/ (HCS II)
12 Dec
12 Dec
1:48 p.m.
dmc!njc(a)ns2.ezwind.net wrote:
This is something I get hit with on a daily basis. On
the one hand I need
to have better than 64M for Windows!?! But my PIC projects barely need the
1024 bytes of ROM/128 bytes of RAM. I often wonder if 16M of RAM will be
enough for my VAX to run. Then I realize that it's not a Windows machine
and I'm happy again. :-)
Remember Linux too needs lots of memory. With >16
meg on a video card
your OS needs about 16x that. It is the video display that is the
killer.
--
Ben Franchuk --- Pre-historic Cpu's --
www.jetnet.ab.ca/users/bfranchuk/index.html
13 Dec
13 Dec
12:14 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 248 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20011213/7c469d22/at…
12 Dec
12 Dec
2:28 p.m.
Tony Duell wrote:
X - Windows !
--
Ben Franchuk --- Pre-historic Cpu's --
www.jetnet.ab.ca/users/bfranchuk/index.html
Remember Linux too needs lots of memory. With
>16 meg on a video card
your OS needs about 16x that. It is the video display that is the
killer.
Since when has linux needed a video display card at all, let alone one
with 16M of RAM?
-tony
14 Dec
14 Dec
1:12 p.m.
A non-text attachment was scrubbed...
Name: not available
Type: text
Size: 855 bytes
Desc: not available
Url :
http://www.classiccmp.org/pipermail/cctalk/attachments/20011215/44bb7c61/at…
4:49 p.m.
On Sat, 15 Dec 2001, Tony Duell wrote:
Firstly, I'll accept that X needs a graphics
display, but surely you can
run the applications on a linux box and the X-server on another machine
(including a dedicated X-terminal). So the linux box only needs a
graphics card if it's running the X-server
What about the print-only X-server? I've used it with a cardreader and
lineprinter. It's painful, but it works. I suspect it would be much less
painful on a CRT terminal.
Secondly, running linux does not imply running X.
Plenty of programs will
run on a text-only command-line type of system. You'd need a video card
for that, although not a graphics-capable one.
I believe Linux will now run with a serial terminal. NetBSD certainly
does.
Thirdly, is there any good reason why you can't
use a serial terminal
linked to an RS232 port any more? In which case the PC wouldn't need a
video card at all, unless it needs one to pass the POST (and you don't
know how to patch the bios to get round it).
This should work just fine. You just have to compile the kernel with the
necessary options.
Peace... Sridhar
6:04 p.m.
On Fri, 14 Dec 2001, Boatman on the River of Suck wrote:
All the kernel needs is serial and serial console support, which is
the default in all the distros I play in. You just have to know the
boottime parameters. But, again, a lot of desktop BIOS's won't POST at
all without a graphics card installed. And most folk who know how to
patch a BIOS aren't running PCs.
Interesting fact: RedHat now accomodates a serial-console install, but
even done like that, the installed system boots looking for a VGA
console. You have to hand-edit the boot configuration after the install,
before you reboot.
Doc
I believe Linux will now run with a serial terminal.
NetBSD certainly
does.
AFAIK, Linux has always run with just a serial terminal. It's only
lately (~18 months, I think) that you could really install it that way
Thirdly, is
there any good reason why you can't use a serial terminal
linked to an RS232 port any more? In which case the PC wouldn't need a
video card at all, unless it needs one to pass the POST (and you don't
know how to patch the bios to get round it).
This should work just fine. You just have to compile the kernel with the
necessary options. 
13 Dec
13 Dec
3:59 p.m.
On Thu, 13 Dec 2001, Tony Duell wrote:
Since when has linux needed a video display card at
all, let alone one
with 16M of RAM?
I'm pretty good at making small distros of FreeBSD. Some people like me
have gotten in to run in 4MB. The least I have ever done is 8MB. And
it's not unbearably slow on a 25MHz 386 embedded card. I suspect Linux is
similar.
--
Jeffrey S. Sharp
jss(a)subatomix.com
4:21 p.m.
On Thu, 13 Dec 2001, Jeffrey S. Sharp wrote:
On Thu, 13 Dec 2001, Tony Duell wrote:
I've gotten NetBSD running fairly well in 2 MB.
Peace... Sridhar
Since when has linux needed a video display card
at all, let alone one
with 16M of RAM?
I'm pretty good at making small distros of FreeBSD. Some people like me
have gotten in to run in 4MB. The least I have ever done is 8MB. And
it's not unbearably slow on a 25MHz 386 embedded card. I suspect Linux is
similar. 
4:34 p.m.
On Thu, 13 Dec 2001, Jeffrey S. Sharp wrote:
On Thu, 13 Dec 2001, Tony Duell wrote:
I started out with Linux on a 386DX-25 with 4MB ram, so I know that works.
You could run X, but it was a little too slow for most things you would
want to use a gui for. A modern Linux dist that uses X would probably not
work too well on such a machine, but you can build up your own system from
source that will work just fine.
-Toth
Since when has linux needed a video display card
at all, let alone one
with 16M of RAM?
I'm pretty good at making small distros of FreeBSD. Some people like me
have gotten in to run in 4MB. The least I have ever done is 8MB. And
it's not unbearably slow on a 25MHz 386 embedded card. I suspect Linux is
similar. 
12:49 p.m.
Ben Franchuk wrote:
dmc!njc(a)ns2.ezwind.net wrote:
> This is something I get hit with on a daily basis. On the one hand I need
> to have better than 64M for Windows!?! But my PIC projects barely need the
> 1024 bytes of ROM/128 bytes of RAM. I often wonder if 16M of RAM will be
> enough for my VAX to run. Then I realize that it's not a Windows machine
> and I'm happy again. :-)
Remember Linux too needs lots of memory. With >16
meg on a video card
your OS needs about 16x that. It is the video display that is the
killer.
I have Linux running on many boxes and they don't need a lot of memory.
The RedHat 7.x install requires I use a lot of memory but most of my
lab boxes are 16M and a 540M disk. They're just servers. The only
reason I've upgrade from 32M to 64 to 384M was Mozilla is such a pig.
But I do like the fact that I can compile the kernel and use X to surf
the net without hitting swap (memory was cheap enough to allow the cost).
I don't remember how much memory is on the video board anymore.
--
Linux Home Automation Neil Cherry ncherry(a)home.net
http://members.home.net/ncherry (Text only)
http://linuxha.sourceforge.net/ (SourceForge)
http://hcs.sourceforge.net/ (HCS II)
2:23 p.m.
At 06:49 PM 13/12/2001 -0500, Neil Cherry wrote:
I have Linux running on many boxes and they don't
need a lot of memory.
The RedHat 7.x install requires I use a lot of memory but most of my
lab boxes are 16M and a 540M disk.
I've got a Linux box next to me with 32Mb RAM, 16Mb non-volatile storage
running linux with a windowing system and applications including a web
browser, mp3 player, mpeg player etc. Linux doesn't have to be big.
Huw Davies | e-mail: Huw.Davies(a)kerberos.davies.net.au
| "If God had wanted soccer played in the
| air, the sky would be painted green"
4:17 p.m.
It was thus said that the Great Neil Cherry once stated:
I have Linux 2.0 running a laptop with 4M RAM and 120M harddrive
(patitioned into 112M for filesystem, and 8M for swap). The installation is
based off RedHat 5.2 and it wasn't easy to actually get installed (RedHat
wanted 16M of RAM for installation, Slackware wanted 8M of RAM, and Tom's
RootBoot Disk barely functions in 4M of RAM) but I was able to get it going.
My main system is Linux 2.0 on a 120MHz AMD 586 (a glorified 486 really)
with 32M RAM with 3G of drive space and it's more than enough for what I do
(I run X, which allows me to run Mozilla off my roommate's box 8-)
-spc (My colocated box is a 33Mhz 486 ... )
Remember Linux too needs lots of memory. With
>16 meg on a video card
your OS needs about 16x that. It is the video display that is the
killer.
I have Linux running on many boxes and they don't need a lot of memory.
The RedHat 7.x install requires I use a lot of memory but most of my
lab boxes are 16M and a 540M disk. They're just servers. The only
reason I've upgrade from 32M to 64 to 384M was Mozilla is such a pig.
But I do like the fact that I can compile the kernel and use X to surf
the net without hitting swap (memory was cheap enough to allow the cost).
12 Dec
12 Dec
2:46 p.m.
Sean 'Captain Napalm' Conner wrote:
I have Linux 2.0 running a laptop with 4M RAM and
120M harddrive
(patitioned into 112M for filesystem, and 8M for swap). The installation is
based off RedHat 5.2 and it wasn't easy to actually get installed (RedHat
wanted 16M of RAM for installation, Slackware wanted 8M of RAM, and Tom's
RootBoot Disk barely functions in 4M of RAM) but I was able to get it going.
My main system is Linux 2.0 on a 120MHz AMD 586 (a glorified 486 really)
with 32M RAM with 3G of drive space and it's more than enough for what I do
(I run X, which allows me to run Mozilla off my roommate's box 8-)
-spc (My colocated box is a 33Mhz 486 ... )
I like debian linux for the simple reason you can upgrade over a modem
internet connection. Red Hat wants a $#%! network card! I downgraded to
windows
since I am using FPGA software and a game or two and needed my other 720
meg HD.
--
Ben Franchuk --- Pre-historic Cpu's --
www.jetnet.ab.ca/users/bfranchuk/index.html
13 Dec
13 Dec
1:02 p.m.
On Wed, 12 Dec 2001, Ben Franchuk wrote:
Remember Linux too needs lots of memory. With >16
meg on a video card
your OS needs about 16x that. It is the video display that is the
killer.
BZZZT!! Wrong.
Linux *likes* lots of memory. I can show you X running on a 386SX with
12M and a 1M video card. Not just a demo; that's my friend's firewall.
Of course, it's a LOT more fun on an Athlon XP with a 64M GeForce & .5G
RAM....
Doc
14 Dec
14 Dec
8:05 a.m.
On Wed, Dec 12, 2001 at 05:48:50PM -0700, Ben Franchuk wrote:
Remember Linux too needs lots of memory. With >16
meg on a video card
your OS needs about 16x that. It is the video display that is the
killer.
X wants lots of memory. And once you have X up you probably want to
run some common bloat-ware (Netscape, Mozilla) and then you will start
to need memory.
But even then, I can run X and a zillion Netscape windows on my
basement server. It has 64MB and, though it does use swap, it doesn't
have to dip very deep.
Granted, that is a lot more RAM than the olden days, but RAM is also a
lot cheaper than the olden days.
-kb
13 Dec
13 Dec
4:23 p.m.
It was thus said that the Great Bill McDermith once stated:
As an interesting side note, from my understanding, the MIPS
processor doesn't have a stack in the same way as the pdp-8
doesn't -- it has to be implemented "by hand", with stores
through a register (stack pointer) with the register incremented
or decremented... Of course, the MIPS has registers (note the
plural), while the pdp-8 has an accumulator.
Yes, on the MIPS, the return address is stored in a register so if the
routine you call makes further calls, that register needs to be saved, and
usually another register is used as the stack register but it's managed ``by
hand'' as it were.
As this is on topic, as MIPS chips have been around for over 10 years ...
-spc (did a bit of MIPS assembly at school ... )
8329
days inactive
8330
days old
24 comments
16 participants
participants (16)
-
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
bill_mcdermith＠yahoo.com -
chris＠mainecoon.com -
cmurillo＠multi.net.co -
dmc!njc＠ns2.ezwind.net -
doc＠mdrconsult.com -
gunther＠aurora.regenstrief.org -
Huw.Davies＠kerberos.davies.net.au -
jss＠subatomix.com -
kentborg＠borg.org -
MRC＠CAC.Washington.EDU -
ncherry＠home.com -
spc＠conman.org -
tothwolf＠concentric.net -
vance＠ikickass.org