shankar@src.honeywell.COM (Son of Knuth) (11/23/88)
In article <11562@cup.portal.com> bcase@cup.portal.com (Brian bcase Case) writes: >> mov lower,i >> bra entry >>body foo >> add step,i >>entry cmp i,upper >> bge body >> >>Statically, same number of instructions; dynamically, less except in the >>zero-trip case. But look, the add, compare, and branch are consecutive. > >Ok, but notice the label in the middle of the add-compare-branch sequence? >I don't think it is possible to specify the ACB instruction in a version >that has a branch destination in the middle! This is one of the points of >RISC: Hey, *I'M* the compiler, let *me* decide on the semantics of >instruction sequences. But this can be transformed into: bra entry body foo acb step,i,upper,body (or whatever the ACB operands are) entry cmp i,upper bge body This doesn't justify the ACB instruction - but it does point out its usefulness in the above example, assuming it doesn't take too many microcode cycles.
shankar@src.honeywell.COM (Son of Knuth) (11/23/88)
Sorry for the last post on CAMs - I got the wrong article. onward - It seems that content addressible memories, although present an awful lot in the literature over the years, have never really taken off. Any comments on why?
lpelleti@enint.Wichita.NCR.COM (Larry Pelletier) (12/07/88)
In article <12371@srcsip.UUCP>, shankar@src.honeywell.COM (Son of Knuth) writes: > > It seems that content addressible memories, although present an > awful lot in the literature over the years, have never really taken off. > Any comments on why? There was never a "popular" programming paradigm that could really take advantage of content addressible memories. Although some things could be done, it really didn't help the concepts of data and code in languages such as Fortran, Cobol, Pascal, or C. Now that we are seeing the emergence of object-oriented programming (it's no longer just a toy :-)), we will begin to see a growing popularity in content adressible memories. -- Larry Pelletier Advanced Development, E&M Wichita <L.Pelletier@Wichita.NCR.COM> <{ece-csc,hubcap,gould,rtech}!ncrcae!ncrwic!l.pelletier> <{sdcsvax,cbatt,dcdwest,nosc.ARPA,ihnp4}!ncr-sd!ncrwic!l.pelletier>
hammond@faline.bellcore.com (Rich A. Hammond) (12/09/88)
The reason that content addressable memories haven't caught on is rather simple. From an IC manufacturing view, there is no "one size fits all" version to make. To get reasonable performance one needs to have the entire word width on a chip, one can't make Nx1 chips and stack them up to the required word width. This gives severe I/O problems for interesting (48 bits and more) size words, either it takes chips with lots of pins (read lots of $$) or you multiplex I/O and performance falls down to the level of a RISC processor with cache, which means you also lost the sale. Appendix: Why can't you have x1 chips? Because you need to know that the whole word matched, matches of portions of the word aren't enough. So, an Nx1 chip would need roughly log (base 2) of N pins to communicate with the other chips and could take multiple cycles to arrive at a match/no match decision. Reducing the time to match/no match appears to require increasing the number of pins. And these communication pins have to have pretty hefty drivers on them. Rich Hammond
henry@utzoo.uucp (Henry Spencer) (12/10/88)
In article <367@enint.Wichita.NCR.COM> lpelleti@enint.Wichita.NCR.COM (Larry Pelletier) writes: >> It seems that content addressible memories, although present an >> awful lot in the literature over the years, have never really taken off. >> Any comments on why? > >There was never a "popular" programming paradigm that could really take >advantage of content addressible memories... Also, and more significantly, content-addressible memories are inflexible and are significantly more expensive to make than ordinary memory (they are more complex and there is much less demand to bring production volumes up). It has generally been more cost-effective to punt this problem to software. Schemes like hashing, done cleverly, are often almost as good. And they don't need expensive special hardware. (If you want a parallel, consider Multics vs. Unix. Despite its vastly greater complexity, Multics is arguably a better system. Unfortunately, it ran only on specialized and expensive hardware. Unix doesn't do some things nearly as nicely, but it runs on anything, which is why it is orders of magnitude more popular.) -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
EGNILGES@pucc.Princeton.EDU (Ed Nilges) (12/12/88)
In article <367@enint.Wichita.NCR.COM>, lpelleti@enint.Wichita.NCR.COM (Larry Pelletier) writes: >There was never a "popular" programming paradigm that could really take >advantage of content addressible memories. Although some things could be >done, it really didn't help the concepts of data and code in languages such >as Fortran, Cobol, Pascal, or C. The REXX language has content-addressibility in software that could be hardware-assisted, but is not at this time. For example, in REXX, if name="MRED" and address.MRED="Happydale Farms", then address.name will get the address of Mr. Ed. Also, what about LISP? However, the problems described by subsequent posters to this thread apply to REXX. Edward Nilges "Where is the wisdom we lost in knowledge? Where is the knowledge we lost in information?" - T. S. Eliot
mslater@cup.portal.com (Michael Z Slater) (12/12/88)
> Why are there no content addressable memories?
A timely question - on Dec. 5, AMD introduced the 99C10, claimed to be the
first VLSI CAM. Size is 256 words, word width programmable to 16 bits or
48 bits. Match detection is 100 ns, technolog is CMOS, package is 28-pin
DIP, and price is $42.50 in 100s. Supposedly now in production.
Michael Slater, Microprocessor Reportshankar@src.honeywell.COM (Son of Knuth) (12/13/88)
In article <6694@pucc.Princeton.EDU> EGNILGES@pucc.Princeton.EDU writes: >In article <367@enint.Wichita.NCR.COM>, lpelleti@enint.Wichita.NCR.COM (Larry Pelletier) writes: >>There was never a "popular" programming paradigm that could really take >>advantage of content addressible memories. Although some things could be >>done, it really didn't help the concepts of data and code in languages such >>as Fortran, Cobol, Pascal, or C. That's probably correct with procedural languages, but how about languages like Prolog or other logic languages? I believe that the use of CAMs would lead to significantly greater performances then the use of the more traditional indexing schemes for rule unification and retrieval, despite problems with inherently sequential portions of the problem. CAMs can also be used for maintenance of the binding environments. As far as procedural languages go, what we need is a language that supports associative data structures (tables?), but perhaps this is a solution searching for a problem. Then again, maybe it's a feature that was never supported precisely because of the lack of CAMs. > Also, what about LISP? How do CAMs help LISP?
phil@diablo.amd.com (Phil Ngai) (12/13/88)
Since there has been all this talk about CAMs, I am taking the liberty
of including a press release on my company's product. (if I get flamed
for this then I won't do it anymore)
"The industry's first VLSI CAM is now available from AMD. The
high-performance Am99C10, with a capacity of 256 words and a
user-programmable word width of 16 bits or 48 bits, features a totally
new concept in memory devices -- memory with built-in logic on every
cell.
The Am99C10 CAM is composed of 256 words, each consisting of a 48-bit
register and a 48-bit maskable comparator. Data presented to the CAM
is simultaneously compared to all 256 addresses in a single 100 ns
cycle. When a match occurs, the on-chip priority encoder generates a
match-word address identifying the location of the data in the CAM. If
multiple matches occur, the encoder generates the lowest matched
address. Any or all bits of the comparand value can be selectively
masked, allowing for comparison on only a portion of the data word.
The CAM is ideal for use in high-speed Ethernet and FDDI local area
networks, and in bridging applications where it can operate as an
address filter and perform the network address look-up function. The
Am99C10 CAM also has applications in database machines, file servers,
image processing, and neural networks.
For more information, contact Barbara Kern, (408) 982-7451."
Please note the following disclaimers:
* I am not an official spokesman for the company.
* Any mistakes made in the transcription are my fault.
* I know nothing about this device besides what you just read.
I work in another group entirely and am merely posting this as
a service to the readers of this group. Please contact the
listed person if you have any questions or comments.
--
Phil Ngai, phil@diablo.amd.com | Freeways used to be a low income
{uunet,decwrl,ucbvax}!amdcad!phil | housing program. aglew@mcdurb.Urbana.Gould.COM (12/14/88)
>"The industry's first VLSI CAM is now available from AMD. The >high-performance Am99C10, with a capacity of 256 words and a >user-programmable word width of 16 bits or 48 bits, features a totally >new concept in memory devices -- memory with built-in logic on every >cell. I think this press release expresses the basic problem with CAMs - they are too small. For the tasks that really need CAM type parallelism, 256 words is far too few. To process really large data sets this way you will have to load the CAM, match, load the CAM again, match, and so on... However, it's a start. AMD's CAM will be useful for applications that can afford to put enough of them together to make a real system, as well as for special purpose applications, like searching an entire track of a disk for a given pattern. Out of curiousity, what other applications are people buying the AMD CAM for (as opposed to wanting to apply it to)?
gsarff@meph.UUCP (Gary Sarff) (12/16/88)
In article <13308@srcsip.UUCP> shankar@src.honeywell.COM (Son of Knuth) writes: >As far as procedural languages go, what we need is a language that supports >associative data structures (tables?), but perhaps this is a solution >searching for a problem. Then again, maybe it's a feature that was never >supported precisely because of the lack of CAMs. The languages SNOBOL4,SPITBOL (and others of their relations) and the language Icon all have associative tables as first class data structures, i.e. they can be passed as arguments to functions, returned as results, assigned, compared, an entire table can be an element of a larger aggregate type such as a field in a record, an array element etc. CAM's sound ideal for this since these languages pass around descriptors for these tables rather than the tables themselves and the elements in the tables are also descriptors that would fit into CAM memory locations. ------------------------------------------------------------------------ "Those whom the gods would destroy, they first make mad" He who steals my core-dump, steals trash
seanf@sco.COM (Sean Fagan) (12/16/88)
In article <367@enint.Wichita.NCR.COM>, lpelleti@enint.Wichita.NCR.COM (Larry Pelletier) writes: >There was never a "popular" programming paradigm that could really take >advantage of content addressible memories. Although some things could be >done, it really didn't help the concepts of data and code in languages such >as Fortran, Cobol, Pascal, or C. I think that CAM would help AWK in many circumstances (accessing any member of an array would help *alot*), but I haven't actually sat down and done any work on it. Has anybody? -- Sean Eric Fagan | "Do not meddle in the affairs of wizards, seanf@sco.UUCP | for they are subtle, and quick to anger." (408) 458-1422 | Any opinions expressed are my own, not my employers'.
landman%hanami@Sun.COM (Howard A. Landman) (12/16/88)
>In article <12371@srcsip.UUCP>, shankar@src.honeywell.COM (Son of Knuth) writes: >> It seems that content addressible memories, although present an >> awful lot in the literature over the years, have never really taken off. >> Any comments on why? In article <367@enint.Wichita.NCR.COM> lpelleti@enint.Wichita.NCR.COM (Larry Pelletier) writes: >There was never a "popular" programming paradigm that could really take >advantage of content addressible memories. Although some things could be >done, it really didn't help the concepts of data and code in languages such >as Fortran, Cobol, Pascal, or C. The Connection Machine can quite easily perform as a CAM, and this ability is embedded in the CM versions of Lisp and C. For example, in C*, if m is a "mono" (scalar) variable and p is a "poly" (xector) variable, you can do things like: /* Set m to the maximum odd value in p. */ if (p & 1) m = (>?= p); or: /* Loop through all processors that have 61 in p. */ active = (p == 61); /* active is a poly var */ while (active) /* i.e., while *any* value of active is TRUE */ { /* Get address of first remaining one. */ m = (<?= my_address); /* my_address calculated elsewhere */ /* Make sure we don't try it again. */ m->active = FALSE; /*** OTHER OPERATIONS (using m) HERE ***/ } Of course most times you would try to do the OTHER OPERATIONS above in parallel. You can't if they talk to the outside world serially (e.g. printf()), but if you can it becomes simply: if (p == 61) { /*** OTHER OPERATIONS HERE ***/ } I find it pretty natural to express things this way; often it takes less code than straight C, because many loops become unnecessary. From the viewpoint of a CM, a CAM is just not very powerful, because it only implements a very small set of operations. >Now that we are seeing the emergence of >object-oriented programming (it's no longer just a toy :-)), we will begin >to see a growing popularity in content adressible memories. I've worked in Smalltalk, but I don't understand this comment at all. How are CAMs supposed to help OOP? Howard A. Landman landman@hanami.sun.com "It's a lesson to me."
ok@quintus.uucp (Richard A. O'Keefe) (12/16/88)
In article <13308@srcsip.UUCP> shankar@wabasha.UUCP (Subash Shankar) writes: >As far as procedural languages go, what we need is a language that supports >associative data structures (tables?), but perhaps this is a solution >searching for a problem. SAIL is just such a language. I'm surprised that no-one has mentioned the CWI(*) monograph "Associons and the Closure Statement" in this discussion. Its topic is "if we had large fast associative memories, how might we use them?" I'm also surprised that no-one has mentioned CAFS, described in ICL Tech J. ICL had several papers on using it; I think they used it in an expert system for hardware diagnosis amongst other things. (*) Well, the organisation is CWI now, but it was MC when this thing came out.
andrew@frip.gwd.tek.com (Andrew Klossner) (12/16/88)
[]
"As far as procedural languages go, what we need is a language
that supports associative data structures (tables?) ..."
So soon we forget .. SNOBOL4, popular in the early 1970s, featured
"tables," like arrays but the subscript could be anything (a string,
a pattern, another table ...)
The language sank under its dependence on Fortran-like unstructured
control flow, and its father went on to invent Icon. I don't know
whether Icon has tables.
-=- Andrew Klossner (uunet!tektronix!hammer!frip!andrew) [UUCP]
(andrew%frip.gwd.tek.com@relay.cs.net) [ARPA]rik@june.cs.washington.edu (Rik Littlefield) (12/16/88)
In article <00051@meph.UUCP>, gsarff@meph.UUCP (Gary Sarff) writes: > > The languages SNOBOL4,SPITBOL ... and > Icon all have associative tables as first class data structures, i.e. they > can be passed as arguments to functions, returned as results, assigned, > compared, an entire table can be an element of a larger aggregate type such > as a field in a record, an array element etc. CAM's sound ideal for this > since these languages pass around descriptors for these tables rather than > the tables themselves and the elements in the tables are also descriptors > that would fit into CAM memory locations. > Yes, these tables are very slick. But when I use them, the "index" values usually end up being strings of substantially more than 32 or 64 bits, and the tables very often have more than 256 entries, sometimes several thousand. Furthermore, these languages don't have declarations that would allow a compiler to determine when a fixed-size CAM would be big enough, so there would be execution time overhead in deciding what implementation to use (pure software or CAM-assisted). I remain unconvinced that the current and foreseeable CAMs would provide enough improvement in this context to justify their cost. --Rik
shankar@src.honeywell.COM (Son of Knuth) (12/17/88)
In article <6746@june.cs.washington.edu> rik@june.cs.washington.edu (Rik Littlefield) writes: > [problems with using a fixed width CAM to access words when the number > of bits in the index is larger then the CAM width] > >--Rik It is not difficult to design CAMs with chaining capability. Probably the simplest way to include this capability is to store a multi-word record in contiguous words, and allow the capability to shift the mark bits (or response registers as some prefer to call it) one bit down. To match a multi-word record, you just match one word, then shift the mark bits one place, match the next word, and on and on. Does the AMD product described previously have chaining capability?
henry@utzoo.uucp (Henry Spencer) (12/17/88)
In article <1929@scolex> seanf@sco.COM (Sean Fagan) writes: >I think that CAM would help AWK in many circumstances (accessing any member >of an array would help *alot*), but I haven't actually sat down and done any >work on it. The question is not whether it would help, but whether it would help *more* than an equivalent investment in making the general-purpose CPU and memory faster, or in smarter hashing algorithms, or in more memory to speed up hashing by minimizing collisions. I doubt it. -- "God willing, we will return." | Henry Spencer at U of Toronto Zoology -Eugene Cernan, the Moon, 1972 | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
aglew@mcdurb.Urbana.Gould.COM (12/17/88)
>/* Written 10:36 am Dec 15, 1988 by gsarff@meph.UUCP in mcdurb:comp.arch */ >The languages SNOBOL4,SPITBOL (and others of their relations) and the language >Icon all have associative tables as first class data structures, i.e. they >can be passed as arguments to functions, returned as results, assigned, >compared, an entire table can be an element of a larger aggregate type such >as a field in a record, an array element etc. CAM's sound ideal for this >since these languages pass around descriptors for these tables rather than >the tables themselves and the elements in the tables are also descriptors >that would fit into CAM memory locations. CAMs would be ideal for this, if they were large enough. Imagine trying to program on a machine where you had 64K of registers, that could not be indirectly addressed, and 256 words of randomly addressable memory. If you wanted to do things like indexing you would constantly be swapping stuff from the non-randomly-addressable memory to the randomly addressable memory. Unless you had a really good compiler that made this transparent, it would eventually become so onerous that you would try some other way, and even if the compiler were good it would probably be slow. Ideally, the entire memory would be both content and randomly addressable. Machines like the Connection Machine make this possible.
chris@mimsy.UUCP (Chris Torek) (12/17/88)
In article <1929@scolex> seanf@sco.COM (Sean Fagan) writes: >"Do not meddle in the affairs of wizards, > for they are subtle, and quick to anger." [And it is also said: Go not to the Elves for counsel, for they will say both no and yes.] >I think that CAM would help AWK in many circumstances .... Well, no and yes. Awk wants to associate by arbitrary-length strings. You would be faced with a choice of variable length matching in hardware, with a very long maximum, or limiting the match length, and both padding input as necessary and breaking up long associations. CAMs are, at present, much better with fixed-length tags. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
rajeevc@mipos2.intel.com (Rajeev Chandrasekhar) (12/19/88)
In article <10748@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew Klossner) writes: >[] > >The language sank under its dependence on Fortran-like unstructured >control flow, and its father went on to invent Icon. I don't know >whether Icon has tables. > I havent used icon for some time, but I remember it having tables, as a data structure. Rajeev Chandrasekhar Intel Corp >> theres someone in my head, and its not me << 2625, Walsh Ave MS SC4-59 (408) 765-4632 Santa Clara, CA 95051 {hplabs,oliveb}!intelca!mipos2!rajeevc
daveb@geaclib.UUCP (David Collier-Brown) (12/19/88)
> In article <1929@scolex> seanf@sco.COM (Sean Fagan) writes: >>I think that CAM would help AWK in many circumstances .... From article <15041@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek): > Well, no and yes. > > Awk wants to associate by arbitrary-length strings. You would be faced > with a choice of variable length matching in hardware, with a very long > maximum, or limiting the match length, and both padding input as > necessary and breaking up long associations. CAMs are, at present, > much better with fixed-length tags. And then again, yes and no... Awk (and SNOBOL, and Icon) use a straightforward mapping of their variable-length strings into table (array) elements, aimed at fast execution on a sequential processor without CAM. That does not mean that one cannot come up with a mapping for processors with CAM... About 5 years ago, I worked on the NDX "fast indexing" machine, discussed in an IEEE Computer special issue (in a box here somewhere (:-)). Its purpose in life was finding documents [elements] containing data which matched certain boolean search terms [indices]. Since the search terms were NOT small or fixed-length, we munged them enthusiastically to allow a fast-search processor (29xx bit-slices) to look through a meg or so of surrogates [indices]. Specifically we used eight orthogonal hash functions to fold them into a fixed-size search space with small (and predictable) possibility of getting false drops [erronious fetches]. This is generalizable to languages like awk, and possibly to others with a need for fine-grained parallellism (prolog, I think). I do wonder if CAMs should not be treated as devices, though, and not folded into those language(s) which do not actually need them... As Henry Spencer points out, a machine with just CAMs runs a good chance of being outperformed by one with valves too. On the third hand, if a CAM was part of the critical "inner loop" of the language implementations (as in prolog unifications?), it would be an obvious candidate for inclusion in the machine... Perhaps in the fpp socket? --dave (I remember the CAFS. Whatever happened to the CAFS?) c-b -- David Collier-Brown. | yunexus!lethe!dave Interleaf Canada Inc. | 1550 Enterprise Rd. | He's so smart he's dumb. Mississauga, Ontario | --Joyce C-B
rik@june.cs.washington.edu (Rik Littlefield) (12/20/88)
In article <13582@srcsip.UUCP>,shankar@src.honeywell.COM (Son of Knuth) writes: > rik@june.cs.washington.edu (that's me) writes: > > [problems with using a fixed width CAM to access words when the number > > of bits in the index is larger then the CAM width, in languages like > > Icon and Awk that support associative tables] > > It is not difficult to design CAMs with chaining capability. > [description of one scheme involving matching the first part, then shifting > the match bits, marking the second part, and so on.] True, but misses the point. These languages are heavily interpreted, with dynamic typing and garbage collection. Most programs do NOT spend the bulk of their time executing table searches. You'd get much more bang for the buck by investing in faster cpu/memory than in CAM support for the tables. BTW, it isn't clear that small CAMs would even make the tables run faster. These languages require "exact match" on table indices. A good hash implementation should require less than 2 probes, independent of table size, and computing the hash is a matter of a few instructions. It's just very hard to believe that repeatedly reloading a CAM unit with hundreds or thousands of entries would be faster. CAM hardware might look better if you needed partial matches on some interior and unpredictable part of the index, so that it would be hard to avoid looking at all the entries. But how often does that come up? --Rik
hamid@goedel.uucp (Hamid Bacha) (01/26/89)
During the month of December, there was an interesting discussion concerning Content-Addressable Memories. With regard to some possible uses of the CAM, there was this exchange: In article <367@enint.Wichita.NCR.COM>, lpelleti@enint.Wichita.NCR.COM (Larry Pelletier) writes: >There was never a "popular" programming paradigm that could really take >advantage of content addressable memories. Although some things could be >done, it really didn't help the concepts of data and code in languages such >as Fortran, Cobol, Pascal, or C. and In article <13308@srcsip.UUCP>, shankar@src.honeywell.COM (Son of Knuth) writes: >That's probably correct with procedural languages, but how about languages >like Prolog or other logic languages? I believe that the use of CAMs would >lead to significantly greater performances then the use of the more >traditional indexing schemes for rule unification and retrieval, despite >problems with inherently sequential portions of the problem. CAMs can also >be used for maintenance of the binding environments. I recently developed a Prolog Abstract Machine for content-addressable memory (along the lines of the Warren Abstract Machine). This new abstract machine is shown to be superior to the WAM in many respects. It is discussed in detail in a paper that was submitted to the next International Conference on Logic Programming (Lisbon '89). It has also been published as a technical report by the CASE Center (New York State Center for Advanced Technology in Computer Applications and Software Engineering) at Syracuse University. Anybody interested in obtaining a free copy of this report should contact Donna McCammon at (315)-443-1066 or write to her at: CASE Center 120 Hinds Hall Syracuse University Syracuse, NY 13210 The technical report number is: 8816 and the title is: "Beyond the WAM: A PAM for the CAM" (a Prolog Abstract Machine for Content-Addressable Memory). Following is a brief list of the advantages that this abstract machine model enjoys over the Warren Abstract Machine: *When binding a variable, there is no need to check whether it should be trailed. *No trailing means no resetting of variables on failure, and no trail to manage. *No need to check for unsafe variables because there are none. *No read or write mode when dealing with lists and structures. This eliminates the S register. *No need to initialize unbound variables when a structure is built. Arguments of structures are accessed by position and their absence from the CAM indicates that they are unbound. *Fewer number of instructions means a less complex compiler and a smaller emulator. The 26 GET, PUT and UNIFY instructions from the WAM are replaced by 15 new instructions that are no more complex than their WAM counterparts.
aglew@mcdurb.Urbana.Gould.COM (01/28/89)
>/* Written 9:22 pm Jan 25, 1989 by hamid@goedel.uucp in mcdurb:comp.arch */ >I recently developed a Prolog Abstract Machine for content-addressable >memory (along the lines of the Warren Abstract Machine). This new abstract >machine is shown to be superior to the WAM in many respects. It is discussed So, how much CAM do you require for your PAM? All of memory? Or can you have just a small bit of CAM and a large amount of regular RAM? CAM is starting out behind the technology curve. Quite likely, given equal chances, the extra functionality of CAM might prove a win, but it's a long way behind. Possibly the only way to catch up will be to start building CAM based systems for specialized applications, trying to force the semiconductor houses into developing what you really need.
shankar@haarlem.SRC.Honeywell.COM (Son of Knuth) (02/02/89)
In article <28200263@mcdurb> aglew@mcdurb.Urbana.Gould.COM writes: > >>/* Written 9:22 pm Jan 25, 1989 by hamid@goedel.uucp in mcdurb:comp.arch */ >>I recently developed a Prolog Abstract Machine for content-addressable >>memory (along the lines of the Warren Abstract Machine). This new abstract >>machine is shown to be superior to the WAM in many respects. It is discussed > >So, how much CAM do you require for your PAM? >All of memory? Or can you have just a small bit of CAM and a large >amount of regular RAM? Well, perfect opportunity to give a plug for my paper presented at last year's ICLP (Intl Conf Logic Programming). I essentially used a small amount of CAM and larger amounts of RAM arranged in a hierarchy, and my performance estimates seemed to show that you could get good performances through such an approach due to the locality inherent in Prolog. That approach only used CAM to store rules for unification rather then for binding environments, though. In short, the answer is yes, you *can get performance benefits without needing huge amount of CAM storage. --- Subash Shankar Honeywell Systems & Research Center voice: (612) 782 7558 US Snail: 3660 Technology Dr., Minneapolis, MN 55418 shankar@srcsip.uucp {umn-cs,ems,bthpyd}!srcsip!shankar