Hardware

hardware@lists.squeakfoundation.org

22 discussions

List closure
by Bruce O'Neel 22 Jul '23

22 Jul '23

Hello all, This mailing list has been inactive for a long time and as a result it will be closed. Any discussions that you would have had here are very welcome on squeak-dev in order to increase the dynamism of the Squeak community. We of course will keep the archives. Thanks Bruce as a representative of the Squeak Board.

1 0

Obama -- The Judas Goat
by Ron Teitelbaum 25 Jan '09

25 Jan '09

Obama -- The Judas Goat 1/25/2009 By David Duke Judas Goat\ A goat that leads other goats or sheep to slaughter. Also, one who entices into danger and betrays others. The name is an allusion to Judas Iscariot, who betrayed Jesus for 30 pieces of slaughter. (From Merriam Webster�s Dictionary) Barack Hussein Obama is a Judas Goat. Extremist Jews guided Barack Hussein Obama�s career from day one, even all the way back to Harvard Law School. Radical Zionist hitman, David Axelrod previously orchestrated the Jewish-financed and organized defeat of perceived anti-Zionist Sen. Charles Percy. He is the man who ran Obama�s campaign for President and who is his chief handler. Obama�s campaign was overwhelmingly financed by the most powerful Zionist bankers in the world. His campaign�s largest contribution source was the Zionist international banking firm of Goldman Sachs. (FEC campaign records). In both Obama�s Senate and Presidential campaign he prostrated himself before AIPAC (American Israel Public Affairs Committee) promising even more money and blood for Israel�s terrorism than even the supine John McCain, and even more money and blood than the previous Shabbez Goy in the White House, George Bush. Before the Israeli terrorism and mass murder in Gaza, he went to Israel and said that he supported Israel�s planned murderous terrorism against the men, women and children of Gaza. His first act as President-elect was to appoint a rabid Zionist, Israeli dual citizen who served in the Israeli Army as his Chief of Staff, Rahm Emmanuel. As thousands of women and children in Gaza were killed or maimed, Obama remained silent. Within a few days as President Obama supported indiscriminate American missile strikes in villages of our ally Pakistan, a clear continuation of Bush�s policies. He completely supports the theft of trillions of American taxpayer dollars to the Zionist international bankers. Eighty percent of American Jews voted for Obama, and all the main leaders of the Jewish Supremacist state of Israel have proclaimed Obama as the perfect man for U.S. President. What better for the Zionists to have their own servant perceived as a clean break from the Jewish extremist-controlled Bush administration? What better than for the Zionists than to have their Shabbez Goy be treated by the world�s press and even by much of the anti-Zionist community as a man of �real change?� What better for the Zionists than for the world to think that Obama will be a change from the Zionist-controlled policies when he willing to do anything that Israel demands? What better for the Zionist murderers to have their craven puppet be looked at by the whole world as a man of honor and integrity and fairness. In the slaughterhouse, the Judas Goat is often painted with bright colors, adorned with strong, sweet scents to lure the sheep to their pens and to their death. Obama, the Judas Goat of our time, is looked upon by millions of Zionist-propagandized sheep as the man who will lead them to salvation. Instead, he leads America, Palestine and the world to the bloody altar of Jewish Supremacism. Any supposed anti-Zionist who praises Barack Obama is actually aiding this Judas Goat to lead us all to slaughter. Every person who truly opposes Jewish extremism must speak out and expose the Judas Goat named Barack Obama! -- Dr. David Duke Former Member of the House of Representatives State of Louisiana United States of America It is up to you the people of the United States who can still think freely, and up to all of the people of the world who are able to see through the deceptions of the Zionist-influenced Global media -- to get this simple, powerful message to everyone on earth. Email this message to your friends, post it on forums and websites and put links to it on every website, facebook or other media in the world. Go and seek out media and Internet sites not controlled by Zionist power. Make youtube videos of this message, (use the short audio and find good illustrative pictures) and post it untill your fingers are worn and tired, print it and mail it to newspapers or any media outlet that has still not fallen under the propaganda of the Zionists. Let the world know the truth. Person by person, in the USA, Canada, UK, France, Germany, Italy, japan, Russia, China, Africa, Palestine, South America and across the whole world this Judas Goat must be exposed for what he is, so that when begins to do his evil for Israel, the whole world will know exactly what is going on and resist! Source : http://www.davidduke.com/general/obama-the-judas-goat_7317.html ------------------------ Why is the President of Israel, the terrorist who just oversaw the Zionist mass murder and maiming of thousands of Palestinians so happy that Obama is President of the USA? by David Duke Read the excerpt from the Israeli News about how President Perez and Israel think that Obama�s becoming U.S. President is great day for Israel. "Israel�s President Shimon Peres ecstatic over the election of Obama" Ronen Medzini Israel News Jan. 21 �Today is a great day not only for the United States of America, but for the entire world,� President Shimon Peres wrote in a letter addressed to Barack Obama on the day of his inauguration as president of the United States. �Obama was elected by the United States, but as a matter of fact, he was chosen by the whole of humankind,� Why is Peres so ecstatic? Why shouldn�t he be, he knows that Obama is completely in the grip of the extremist Jewish Zionists in America, and he knows that the greater Obama�s popularity and idol worship, the more Obama can do for the International Zionist Cause. Any thinking and caring human being who realizes that the Zionist-controlled American foreign policy has been a disaster for the robbed and murdered people of Palestine, Lebanon, Iraq and a catastrophe for the 50,000 American wounded in Iraq and Afghanistan, as well as an economic catastrophe for the hardworking Americans who pay trillions to finance these wars for Israel -- must wake up the fact that supporting Obama and increasing his popularity will only aid Zionist terrorism, war, and their murder and oppression of the Palestinians. It will also hasten the economic suffering of billions of people around the world as his popularity enables him to more easily aid the Zionist International Bankers steal the wealth of the United States, Europe and the world. Obama is totally in the bloodstained and green ink- stained hands of the Zionists. The hard truth is that the more good will and support Obama has also gives more power to support the Zionist agenda! Mark my words. The Obama Presidency will be disaster for America and for the world. Obama was put into office by the Zionists. His top two cohorts for years have been the radical Jews David Axelrod and Rahm Emmanuel. Both have long records of radical Zionism and have been attack dogs against anyone perceived as having the slightest opposition to Israel. One such victim was Sen. Charles Percy, who both men worked to defeat and destroy because he dared to only be 99 percent rather than 100 percent pro-Israel. Rahm Emmanuel, a dual citizen of Israel who went to fight for Israel, he has a long pedigree of Jewish extremism. His father served in the Irgun Terrorist Gang and he himself is named after an Irgun terrorist. Zionist leaders in Chicago actually call Obama �the first Jewish President� and boast that Jews were key players in Obama�s every step up the ladder to President. from the very earliest days, extremist Jews were the largest contributors to his campaign. In the beginning of his Presidential bid, three Hollywood Jews that constantly make movies about Jewish suffering, but never about the Zionist terrorism and theft against the Palestinian people, Steven Spielberg, David Geffen, and Jeffrey Katzenberg raised 1.2 million for Obama in a single Hollywood party. By the time Obama�s campaign was in full swing, he had huge support from the criminal Zionist International Banking firms such as Goldman Sachs and Lehman brothers. Goldman Sachs was Obama�s biggest single contributor, and his vast war chest came not from American manufacturing firms like GM or even American oil companies, (not one was in his top twenty) it was overwhelmingly dominated by Zionist international bankers, the same ones whose thievery and fraud are giving the world this economic depression. For those looking for meaningful social and political change, do you really think it will come from this man who has already been bought heart, head and soul by the most powerful czars of the international financial establishment and the biggest globalists in the world? I know that many are desperate for change, so desperate that you want to believe anything. But in the face of these facts can�t you see that Obama will be even more dangerous to freedom and justice than even George Bush and his band of Neocons were. What better way to wipe out George Bush�s hated legacy and make the world believe that America has really changed than with the election of Obama. But, all the real Zionist power, Zionist media power, and Zionist financial power in America is still in place, even stronger than ever. Many Americans and others around the world who want to do good are now telling us how wonderful Obama will be as president. What a great change it will be from the old policies. This is because of the Zionist-Controlled media hype, promoting Obama. The fact is that these poor sods are ignorantly helping the radical Zionist agenda in Israel and around the world. Every day that you don�t help expose Obama for the Zionist servant that he actually is, his popularity will be a greater danger to peace and freedom. If the Zionist terrorist Shimon Perez is happy about the coronation of Obama, then why in the hell should you be? �David Duke Source : http://www.davidduke.com/general/7303_7303.html ------------------------------------- You or someone using your email adress is currently subscribed to the Lawrence Auster Newletter. If you wish to unsubscribe from our mailing list, please let us know by calling to 1 212 865 1284 Thanks, Lawrence Auster, 238 W 101 St Apt. 3B New York, NY 10025 Contact: lawrence.auster(a)att.net -------------------------------------

1 0

Obama -- The Judas Goat
by Ron Teitelbaum 25 Jan '09

25 Jan '09

1 0

SiliconSqueak
by Jecel Assumpcao Jr 05 Nov '08

05 Nov '08

As I mentioned in my talk at the Squeak BOF (on October 21 at Nashville), I have suspended the RISC42 effort to focus on a processor optimized for Squeak. The idea of this SiliconSqueak is to be fully compatible with software implementations of the VM and to be as compact as possible to allow multiple cores per system. Since this will be essentially a hardware implementation of the Interpreter, it is not reasonable to expect the same results as you would get with a sophisticated adaptive compilation system on the RISC42. But it should be more than good enough and will run the software people already have instead of forcing them to migrate to my own Neo Smalltalk (though I was extremely pleased with how the design for that turned out). The idea is to instead incrementally improve Squeak. The reason for this change in direction is that I was contacted three months ago by a group developing neat things in Squeak and they needed a product like this. I had already studied the issues regarding Squeak compatible hardware in the past few years (http://people.squeakfoundation.org/person/Jecel/diary.html?start=2) and looking carefully at this one more time it seemed like a practical and interesting project. You might consider the Java processor JOP (http://www.jopdesign.com/) as proof that this kind of thing can be done. And David Ungar and Sam Adams' work on the tile64 (also presented at the BOF) as proof that Squeak can run on a large number of cores. I haven't started actual work on this project, yet. But there was an interesting dicussion with Eliot Miranda about his planned bytecodes for Cog since it would be a good idea to track that. Hopefully this will be something that will be practical interest to more people than what I had been doing before. -- Jecel

1 0

tags
by Jecel Assumpcao Jr 09 Sep '08

09 Sep '08

There was an interesting discussion in the "fonc" list a short time ago about trying to make the system as independent as possible from the representation of "tags". I suppose that all of you know that objects in dynamically typed languages are tagged so that the system can know the type of each one at run time. There are several ways of doing this. A simple solution is to have the first word in each object point to some other object (a class, for example) which indicates that type. Another solution is to divide up the memory space into regions and only allow objects of a given type in each region. A variation of this is to reserve some bits in the object pointer to indicate the type. In practice a combination of these is almost always used. For Squeak, for example, there are three systems. The first is using the lowest bit in the object reference to separate small integers (1) from all other objects (0). The second, which applies to the "all other objects" case, uses some bits in a header word as an index into a table which then points to the class. In the third option the header includes a full extra word which is a direct pointer to the class. This method works well because objects are aligned on multiple of four bytes, so all normal pointers have the lowest two bits as 00 and can never be confused with small integers. The problem is that if you add two integers then the result will be wrong: you have to clear the tags, do the addition and then set the tag (just clearing one of the tags has the same effect for addition). Note that we lost one bit of precision for small integers, but pointers are no worse off due to this scheme (we can still address 4GB). For Self the two lowest bits are 00 for small integers (so we lose two bits), 01 for object pointers, 10 for floating point and 11 for header words. This would seem to make access to an object's fields more costly, but in practice most of the time you have a constant offset (or an index register plus a constant) added to a base address and can adjust the constant so no extra operations are needed. The small integers can now be added and subtracted very simply and you just have to watch out for overflow. The floating point numbers got the short end of the stick with a serious loss in precision, but you get better performance than the "boxed" (full objects rather than encoded in object references) floats like in Self. And you can have boxed doubles if needed. The special tags for headers allow you to scan though memory at very high speeds until you find some reference you want and then back up a little to see what object it is in. Without this you have to scan by objects (which normally implies recursion and other complications) to get the same result. For RISC42 I changed the object reference format a while back so that the top two bits are 00 for positive small integers, 11 for negative small integers and 01 or 10 for object references (two sizes of task/object division). Note that the precision of small integers is 31 bits like in Squeak. With this format not only do 32 bit addition and subtraction instructions work just fine, but also signed multiplication and division, shifts and logical operations too. Only rotation instructions don't work. Of course, the result won't be a valid small integer for all inputs. One solution would be to add a second overflow flag to detect this. Another would be to redefine the old overflow flag, but in some cases we would like the old definition. The interesting thing about this scheme is how different the costs are for a software versus hardware implementation. It is a bit complicated to check these flags in software (you need a shift, an exclusive or and a masking operation) and detecting non small integer results is much worse. For the hardware a single exclusive or gate will to the job and detecting overflow adds only a little more logic. So a system that has both a hardware and software-only implementations would be improved by allowing different tagging schemes. This would make sharing images more complicated (but not that much). -- Jecel

1 0

pipeline
by Jecel Assumpcao Jr 12 Mar '08

12 Mar '08

Of the many interesting results mentioned in the first year report from Viewpoints (http://vpri.org/pdf/steps_TR-2007-008.pdf), there is a block diagram of a RISC processor by Chuck Thacker (Xerox Alto, MS TabletPC and others). It is very simple - 100 lines of Verilog is mentioned. Some things that are not explained are easy to figure out, like bit 24 selecting between load constant and regular instructions. The register set seems to be a flat 128 register file, like Knuth's MMIX or the Philips Trimedia. Having tried to develop a compiler for the latter, I must confess that I haven't figured out yet how to make good use of such a resource. One of the reasons why this design is so simple is that it isn't pipelined in the traditional RISC style. Yet it does several things independently (in parallel) and so can execute one instruction per clock cycle. That clock won't be as fast as would be possible in a pipelined design, but given the fast memories available in modern FPGAs the difference won't be too bad. There was an interesting series of articles by Jan Gray in "Circuit Cellar" (http://www.fpgacpu.org/xsoc/cc.html) which I really recommend to anyone who is interested in CPUs and FPGAs. He designed a 16 bit pipelined RISC and adapted LCC to generate code for it. The FPGAs he used in this project were older ones that didn't have any internal memory, but when newer models became available he did a CPU that was very similar but was not pipelined: http://www.fpgacpu.org/gr/index.html None of my stack processors were pipelined (the older Tachyon design was, but it hid the complexities by multiplexing four or more threads in what is known as the "barrel execution model"- http://en.wikipedia.org/wiki/Barrel_processor). It seemed natural, however, that RISC42 should have a five stage pipeline. In fact, I took advantage of the normally invisible bypass circuit in pipelined designs to create the "cascade" instructions with register K and so reduce the pain of a two address instruction set. I have not been very happy with the complexity due to the combination of various features. RISC42 is supposed to be educational and not just functional and fast. So it would be better for it to be a much simpler single clock design. That eliminates the K register, but R15 can fill that role pretty well (even better since it allows task switching between cascaded instructions). There are no programmer visible changes to the design except for the slower clock. FPGAs happen to be very good for pipelined designs since they have a flip-flop for every logic block, so this simplification won't save much space. -- Jecel P.S.: thanks to a tip from Reinout Heeck I seem to have fixed the problem with my swiki (it was an "intrusion detection system" in the ADSL modem)

1 0

Re: [Hardware] display registers (was: RISC42 history)
by Jecel Assumpcao Jr 03 Mar '08

03 Mar '08

I had previously given an overview of the changes in my processor designs, but I have made yet some more changes since then. The most significant one was hiding the register banks under a sliding window. The 15 register window can be moved up or down by any number of registers. This is backed up by two banks for 16 registers each. When the window moves such that R0 is no longer in bank A, then the two banks are adjusted so that it is. Register 15 reads as zero when explicitly addressed as a source. The original design had two prefix instructions to extend immediate values from 4 to 16 (or 32) bits. But prefixes are more interesting when used to get arbitrary sized values, not just two possible sizes. And they had the problem that their bits had to be shifted before they could be combined with the four bits in the base instruction. So I felt that it would be better to reserve the immediate values of 14 and 15 to indicate that the actual value is the following 16 or 32 bits. These bits will be aligned correctly, which helps a lot. This freed up two instructions which were used for "store byte", eliminating the tagged pointers (but there are still tags for integer/objects) to make it easier to adapt C compilers. There is no "load byte" but this isn't hard to emulate with existing instructions. The "jump and link" now doubles as "send" and as extension instructions. Since the stack would have to be adjusted before and after every send (though though such "change stack" instructions can be merged when back to back) it is tempting to add this function to the "jump and link" instruction itself in order to make the code shorter. But then a special "return" instruction would be needed and the original state of the stack would have to be saved somewhere. A good place for this would be the top four bits of the PC. This would limit the code cache to 256MB, but considering that the Transmeta chips only had 8MB this isn't as small as it might seem. I haven't made this change, yet. I have changed my internet connection (same ISP, though) and have been having problems with my swiki pages since. They work just great on the local network, and the regular pages at port 80 seem fine. But when you make more than four simultaneous connnections to port 8080 it locks up for some ten minutes. Each swiki page has a bunch of icons, so this problem happens all the time. Cheers, -- Jecel

1 0

Re: [Hardware] RISC42 history (was: Assembly Language)
by Klaus D. Witzel 09 Oct '07

09 Oct '07

Hi Jecel, on Tue, 09 Oct 2007 03:40:28 +0200, you wrote: [ :many | many, interesting things ] > ... With agressive inlining, however, highly optimized > methods will need to access more registers. I've thought over this for [howmany?] years now, time again. It is perhaps possible to introduce inlineable blocks which don't need much more register space. Access to outer scope could be done similiar to what the B5xxx did with her display registers. And it is well known that that lad runs perfectly with just 4 display registers (and only very large sisters of her had surplus, $$ expensive display registers). The concept at work here is D[ll] with ll=the current scope level (in our case the inlined material's data). D[ll] points to D[ll-1], etc, (in our case to whom it was inlined), from which data registers can be loaded. What do you think? > Since the prefix > instructions were only defined for immediate operands, their use with > non immediate instructions has been defined to extend the destination > and source fields. This allows up to 256 extra local registers to be > used. Yeah, that's an alternative. > The prolog and epilog code for such methods will not be trivial as > they will have to deal with allocating a continuous chunk of physical > registers among the various threaded lists of frames. But this shouldn't > be a problem as such methods will execute for quite a while (or they > wouldn't have been compiled with so much inling in the first place) > making this overhead worth it. > > And this is what I have today and am starting to implement. It is a bit > more complex than I would like, but I feel the extra features are > important for it to do well interpreting bytecodes, running highly > factored native code and running deeply inlined native code. Good luck! Cheers Klaus > -- Jecel > _______________________________________________ > Hardware mailing list > Hardware(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/hardware

2 1

RISC42 history (was: Assembly Language)
by Jecel Assumpcao Jr 09 Oct '07

09 Oct '07

On Mon, 17 Sep 2007 21:10:44 -0300 I wrote: > The > idea is to make this development as open as possible, with a public > version control system, a bug tracker and a blog. This would be a good > thing to implement in Seaside but perhaps I should start out with > existing solutions to get results faster? I am thinking that it would be a good idea to create a "Plurion Maker" application in Squeak rather than implementing this system directly in Verilog (or VHDL, which I don't like as much but is popular in Europe and in schools). You would set a few options with a nice interface and then press a button to get one big HDL file plus one or two little configuration ones. This is much more work to implement initially, but much nicer to use in the long run. Other processor cores have similar systems, sometimes implemented as a bunch of Perl and Tcl scripts. On the Smalltalk side, we have Idass as an inspiration (though this would be very specialized compared to that): http://www.xs4all.nl/~averschu/idass/ > It would be interesting if people could look at the (extremely bare, > sorry) description of the instruction set (Matthew gave the link in his > email, but here it is again - http://www.merlintec.com:8080/hardware/32) > and give their opinions. The processor design has been changing, so people who looked at it a while back might not have seen the recent ideas. And it is hard to have an opinion without knowing its history: I started out (1998) trying to build the ideal hardware target for a Self-style adaptive compilation system. The result was Tachyon which could execute four MOVE instructions per clock as long as the compiler could schedule them. It had an interesting support for PICs with up to three entries. There was dedicated hardware for the translation cache, so this was very similar to what Transmeta later released. By 2001 it was becoming obvious that the software side of the project was very large, and with new FPGAs coming out more internal memory it became pratical to implement several simpler processors (Plurion) and get roughly the same performance as one big one. And having bytecodes as the native instruction set of these processors the software side would be more comparable to an interpreter. This would not rule out sophisticated optimization later on, though targeting bytecodes would make the adaptive compiler more like AOStA (http://www.esug.org/data/ESUG2003/aosta.pdf) than Self, which is actually a good thing. Even though the bytecode processors were very similar to Forth processor which are very good for low level computing, I felt that a more RISC-like processor would do a better job of handling i/o. So I tried out various designs and the idea was that a Plurion system would be a mix of stack processors for executing user code and RISC-like processors for doing i/o. Having implemented things like serial ports in hardware I had been impressed by how quickly such things grow as you add more and more counters an registers. A processing implementing the same thing in software could be smaller since on board memory is so much denser than random logic in modern FPGAs and a single ALU would be time multipled to handle as many counters as you need. In parallel with these two design efforts (bytecode processor and i/o processor) I also looked at the possibility of doing a microcoded processor for running Squeak. My own bytecodes were so much simpler than Squeak's that they could be directly executed, but it was obvious that a proper Squeak processor would look more like JOP (a Java processor implemented in FPGAs - http://www.jopdesign.com/). The old Xerox D machines and the Lisp Machines were also a good inspiration for this, of course, but the pipelined design used in JOP is more interesting. I did think that JOP was trying to save too much memory: the first pipeline stage looks up the fetched bytecode in a 256 entry memory to get the start address of the first microinstruction, just like the Dorado did. Why not just waste a few words for each instruction and avoid an indirection? Just jump directly to microinstruction BC*4 after fetching bytecode BC and if you need more than four microinstructions you include a jump (this will be a slow instruction anyway, so the jump won't hurt much). Most bytecodes execute in one or two microinstructions and you could use the leftover words for those entries that are longer. You can also make the microcode memory larger than 1024 words and put the rest of the large instructions in this overflow area. When RISCs first came out I used to joke that they were just CISCs that used main memory as their microcode RAM. Adding instruction caches made the two schemes even more similar. As the three designs (hardwired bytecode stack processor, risc-like i/o processor, microcoded Squeak processor) evolved, I started thinking about taking this joke seriously and creating a single merged design. A special small "bytecode mode" RAM would dispatch efficiently to small RISC routines and the instruction cache would hold code for longer bytecodes and native code for stuff written in C and other languages. The instructions were kept short to make compiling from bytecodes to native code less costly in terms of memory and among the many inspirations were Jan Gray's desings and the Data General Nova. The cascade instructions were introduced to make use of the bypass hardware that all pipelined RISCs have anyway. They help out when two address instructions would be awkward (they are often, but not always, good enough). The skip instructions were inspired by the old IBM Stretch (early 1960s supercomputer) design though they are rather different from what had been done there. The stack processors had inherited the PIC hardware from Tachyon. RISC42 got a more general PICMode extension to the instruction cache which is not limited to three entries (it has no limit at all) as in previous designs. All of my designs have had a Mushroom-style virtually addressed data cache so that object tables could be used without the usual overhead (tables are accessed on cache misses, nor on every object field access). Originally RISC42 only had 16 registers, but it was obvious that register windows would make non leaf methods much more efficient and would be a better use of the available FPGA resources. Many people got a bad impression of register windows due to design problems on the Sparc (fixed only in the UltraSparc), but the Altera people said of removing register windows from their Nios II softcore (the original Nios had them) that "it didn't hurt performance too much" so they felt the simplification was worth it. Unlike the Sparc, the register windows in RISC42 are allocated from a list so you can have several threads mixed in the physical registers. With register windows RISC42 became multithreaded like the i/o processors and the Alto since that has worked well for me so far. The next significant change was removing the size of the operand from the store/load instructions and into the pointer itself in the form of tag bits. Though the definition of the C language was created to handle this (that is why you have to cast from a char pointer to a long pointer) most C compilers I have looked at (lcc, tcc and others) have no ways of dealing with this kind of thing since the PDP-11 didn't need it and all modern processors have evolved from it. Looking at gcc it seems that this feature can be added, but until I have actually done it I can't be sure. Handling cascade instructions and skips won't be easy either, but these features can be ignored and it is still possible to generate code for any C application using the rest of the instruction set. The tagged pointers are more fundamental, so the compiler will have to deal with them. But they are important for making Smalltalk and C play nice with each other, so I will put in the effort to make this happen. One nice thing about the old Plurion stack processor is that returns would put the data in the right place for an argument to a send instruction later. In normal Smalltalk implementations you have to keep copying things from the caller stack to the callee stack and then back (the result) again. In addition, it was not easy to implement the most common Squeak bytecodes as just one or two RISC42 instructions. So register 15 was redefined to operate as the top of a small hardware stack. This allows efficient implementation of common bytecodes, access to three register windows at once instead of just two and a lot less copying by compiling returns to put their data directly in their final destinations. Since there is now a special register, there might as well be two: register 14 was redefined as always returning zero. Several instruction sequences were awkward without this, and while it could have been just a software convention to keep R14 always zero there would not be any place to send results that aren't needed. This cut the global registers from four to just two, but that should be enough. Even though the register windows only have six registers each, that is enough for most non leaf methods. Leaf methods can use two register windows at once, and with the new stack they have some extra room to keep their data in. With agressive inlining, however, highly optimized methods will need to access more registers. Since the prefix instructions were only defined for immediate operands, their use with non immediate instructions has been defined to extend the destination and source fields. This allows up to 256 extra local registers to be used. The prolog and epilog code for such methods will not be trivial as they will have to deal with allocating a continuous chunk of physical registers among the various threaded lists of frames. But this shouldn't be a problem as such methods will execute for quite a while (or they wouldn't have been compiled with so much inling in the first place) making this overhead worth it. And this is what I have today and am starting to implement. It is a bit more complex than I would like, but I feel the extra features are important for it to do well interpreting bytecodes, running highly factored native code and running deeply inlined native code. -- Jecel

1 0

Re: Assembly Language
by Matthew Fulmer 18 Sep '07

18 Sep '07

CC'ed to the hardware list On Sat, Sep 15, 2007 at 02:26:47PM -0700, Peter William Lount wrote: > Each of the Tile 64 Processors is thousands of more times more powerful > than that old 6502 based Apple ][ system. I can imagine what Gemstone > Warrior would be like on it! Fully object oriented, fully message > oriented, fully 4-D (3D+Time)! > > If you really want a chip to play with as a hobby with potential for > future success play with the Tile 64 chip! > > Smalltalk on the Tile 64 chip will be hot! When will it happen? Jecel Assumpcao Jr. is working on a quite similar project. He is putting Neo Smalltalk [1] on a 9-core Plurion [2] processor. He has said he will follow this up with a port of Spoon. More information can be found on his hardware Swiki [3]. I'll be working with him on this project as part of my graduate studies. [1]. Neo Smalltalk: http://www.merlintec.com:8080/software http://wiki.squeak.org/squeak/5637 [2]. A very out-of-date description of Plurion architecture: http://www.merlintec.com/download/plurion.pdf A description of the actual processor being used: http://www.merlintec.com:8080/hardware/32 [3]. Jecel's hardware Swiki: http://www.merlintec.com:8080/hardware -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Hardware