Re: [fonc] My annual hey, look at this post: Ivan Sutherland's FLEET architecture
Nikolay Suslov wrote: Just to mention, that Thacker's BEE FPGA is not another hardware project, but the emulation engine, where Fleet (the novel processor architecture) is being researched and emulated. A box packed full of FPGAs capable of 4 teraops/second isn't a hardware project? I beg to differ. :-) One of the target use-cases for the BEE is indeed to simulate new processor architectures. However, that's not all it's for. Among other things, the beecube.com webpage says that it can be used for FPGA based computational acceleration in HPC and High performance digital signal processing. Cheers, Josh Regards, Nikolay On Sun, Jul 26, 2009 at 12:40 AM, Joshua Gargus sc...@fastmail.us mailto:sc...@fastmail.us wrote: I just noticed this: http://fleet.cs.berkeley.edu/ It seems relevant to this list both because it's an ambitious re-imagining of the foundations of processor architecture, and because of the intellectual heritage between Ivan and Alan. I know that VPRI is keeping an eye on other hardware projects, like Thacker's BEE FPGA boxes, and I wonder how relevant Sutherland's work might be to VPRI in, say, 1 or 5 years? Cheers, Josh ___ fonc mailing list fonc@vpri.org mailto:fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] My annual hey, look at this post: Ivan Sutherland's FLEET architecture
I just noticed this: http://fleet.cs.berkeley.edu/ It seems relevant to this list both because it's an ambitious re-imagining of the foundations of processor architecture, and because of the intellectual heritage between Ivan and Alan. I know that VPRI is keeping an eye on other hardware projects, like Thacker's BEE FPGA boxes, and I wonder how relevant Sutherland's work might be to VPRI in, say, 1 or 5 years? Cheers, Josh ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] SVN down
Hi, the SVN at piumarta.com has been down for a couple of days. Ian, are you aware of this? Cheers, Josh ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Coding Standards
Michael FIG wrote: Kjell Godo [EMAIL PROTECTED] writes: So what you're saying is that the idc which is written in C compiles C like code into machine code? idc is written in Pepsi. You may be confused because the bootstrap .o.c files are included in the SVN checkout, at least until idc targets Coke instead of C. And then that machine code compiles Smalltalk like idst/Pepsi into machine code? No, GCC compiles the C code (until bootstrap). The idst/Pepsi compiles itself into machine code. And this bootstrapping happens over and over again and not just once or twice in a year. The bootstrapping is when Pepsi and Jolt are unified into Coke, and that need only happen once. Right, but there was also an initial stage in the bootstrapping where a Pepsi compiler was written in C (C++?)... this is Phase 1 in section 6.1 of Accessible Language-Based Environments of Recursive Theories (ALBERT). This one has apparently already been discarded; now we just start from the (Pepsi-compiler-generated) files in boot/. This first one is a normal bootstrap, the exciting one will be when Pepsi and Jolt are unified into Coke. This is Phase 4 in section 6.1 of ALBERT. Cheers, Josh ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] jolt3 [was: Porting CodeGenerator vs VPU]
Kjell Godo wrote: AST = Abstract Syntax Tree? Yes. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Slides and Videos from 2008 LLVM Developer Conference
I haven't had time to delve into this myself, but I imagine that many here will be interested... http://llvm.org/devmtg/2008-08/ Cheers, Josh ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] sideways composition and metacircularity
On Jun 12, 2008, at 7:02 PM, James McCartney wrote: I hope this doesn't come across as adversarial since I am sincerely interested in this, but I am troubled by the sideways composition paper. It seems as if it is an existence proof that the id object model's intention of having messaging semantics that are described entirely in terms of those same objects and messages is not attained. The Open, extensible object models paper (henceforth OEOM) does not claim to implement *all* possible messaging semantics, only *an* extensible object model and associated messaging semantics. Implementing sideways composition required changing send and bind which are not redefinable within the system. Not within the object model described in OEOM, true. It's a simple, fixed object model implemented in C. However, have you read the COLA paper (http://piumarta.com/papers/colas-whitepaper.pdf)? Section 6 describes a circular system where objects represent behavior, and the behavior is used to implement the object semantics. It also describes a multi-stage bootstrapping process by which the circular system can be realized. The current implementation in SVN has reached the stage where Pepsi-in- Pepsi has been used to implement Jolt. The final step of implementing Pepsi-in-Jolt has not yet occurred. The reason that I mention this is to highlight that sideways composition via Lieberman prototypes is orthogonal to this bootstrapping process. You can implement Jolt using Pepsi-without- prototypes; once you have it, you can use it to reimplement Pepsi. You can also (and I take this to be the main point of the COLA paper) extend the original Pepsi semantics to include prototypes, all within the running system (and certainly without compiling any more C files). Cheers, Josh Only lookup can be redefined in the vtable. The sideways composition as implemented is still not able to handle multiple delegates. There isn't a way for an object A that wants to delegate first to B and then to C (if B does not already itself delegate to C). The single delegation mechanism is hard coded in bind which is not redefinable from within. -- --- james mccartney ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] New Tech Report from VPRI
Hi all, I feel a bit awkward announcing this (since there are VPRI members who frequent the list), but I think it's of general interest, and also provides a segue to the next email that I will shortly write. VPRI has published Steps Toward the Reinvention of Programming on their website (http://vpri.org/html/writings.htm). It's a synopsis of the work that they've done over the last year; as you might expect, a lot of it involves COLA. It's well worth the read! Cheers, Josh ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Declarative Networking in COLA
After reading the latest VPRI tech report Steps Toward the Reinvention of Programming I was compelled to revisit the Declarative Networking research by Boon Thau Loo and others. The claim is put forth that by specifying network protocols declaratively rather than imperatively, major gains can be realized in three areas: - ease of programming (more concise, understandable, and modular code) - optimizability (applying database optimizations to network queries) - balancing extensibility with security (eg: much more secure than unconstrained mobile code) The first point is probably the most salient to VPRI's research agenda. One impressive example is a factor of 100x reduction in the number of lines of code to implement the Chord DHT, compared to C++. The concise implementation required only 48 rules of NDlog (the Prolog- like language designed for declarative networking). Unfortunately, I don't have time to work on this, but I thought that it might be of interest to Viewpoints or others in the community. Perhaps now that it's Google Summer of Code time, one of the grad students from Berkeley or Penn might be enticed to port P2 to COLA (instead of the yucky lex and yak that the NDlog parser is currently written in); it would be a nice encore to the COLA TCP implementation described in VPRI's new tech report (http://vpri.org/pdf/steps_TR-2007-008.pdf ). BTW, I found the best paper on the topic is Loo's Ph.D. dissertation, entitled The Design and Implementation of Declarative Networks. The conference papers were too terse for me (but maybe not if you are more familiar with database theory than I am). Josh ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
On Dec 6, 2007, at 2:35 AM, Waldemar Kornewald wrote: On Dec 6, 2007 1:48 AM, Joshua Gargus [EMAIL PROTECTED] wrote: Is it correct that we'll have a Lisp-like syntax at the lowest level and a Smalltalk-like syntax above (with some syntax sugar like in eToys?)? (Leaving aside whether eToys should be considered syntactic sugar on top of Smalltalk, any more than C is syntactic sugar on assembler...) Hehe. :) Since we don't know what the eToys-inspired language will be like I expressed it that way. What purpose will the eToys-inspired language have? Will it be primarily for children or will it be more general-purpose like Smalltalk? Will most of the system be implemented in that eToys-inspired language? In which language will the whole system be implemented such that it'll only be about 20K lines? It will be implemented in a variety of domain-specific languages. For example, the code for networking, graphics, and defining new syntaxes might be written in different languages. If I want to write some fancy peer-to-peer system, Smalltalk or Python are not much better than C. What I really want is something like P2 (http://p2.berkeley.intel-research.net/ ) that reduces the amount of code to write by a factor of 100. As I understand it, one of the big goals of the project is that a Smalltalk-like object can trivially send messages to objects generated- by/coded-in JavaScript. You can use any language that you want, yet still have perfectly convenient access to libraries written in other, more popular, languages. What bothers me more is that if the lower-level language is based on Smalltalk syntax then how are the other languages going to easily and comfortably interface with that syntax? It'll probably have to look like a mixture, similar to Objective C. This statement is untrue, and reveals a misconception that explains your determination to get a solid answer about what the syntax will look like. Once you're past the misconception, you will understand that Bert was not being equivocal when he said we do not pick any particular syntax at this point in time. .NET might provide a useful analogy. You can write an application in many different languages that target the CLR (C#, Python, OCaml), and since they all use the same underlying bytecodes and object representation, you can write code in one language that will send a message to an object written in another language even though the syntax of the two languages have very little in common. Very roughly (sorry Ian), you can think of OLA as .NET without the VM. Ian's papers (particularly http://vpri.org/pdf/colas_wp_RN-2006-001-a.pdf and http://vpri.org/pdf/obj_mod_RN-2006-003-a.pdf) describe clearly how this is implemented. Josh Bye, Waldemar Kornewald ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] tutorial
That's not bad. How about simply OLA, since minimalism is such a big part of the whole adventure? Josh On Nov 28, 2007, at 5:30 AM, Steven H. Rogers wrote: Stéphane Conversy wrote: btw, I vote for ZOLA for two reasons: 1. http://acronyms.thefreedictionary.com/zola . Zola is not available in the list of acronyms. (whci hmeans it IS available) 2. http://en.wikipedia.org/wiki/%C3%89mile_Zola: ...but I affirm, with intense conviction, the Truth is on the march and nothing will stop it. — Émile Zola I still work hard to find out what the 'Z' would mean. How about Zen Object Lambda Architecture? # Steve ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] syntax
One thing that I'm surprised hasn't been mentioned in this thread is that the C/L/HOLA is designed to support domain- and mood-specific programming. I think it makes sense to have uniform Smalltalk-like messaging semantics as the default, but to make it easy to shift over to math precedence for domains where it makes sense. This approach risks causing confusion when switching between parts of the program which use different operator precedence. I think that the UI can help with this by making it clear which precedence rules are in effect. I've attached a mock-up of a Squeak workspace with an embedded mathematical expression. It is clear from the font and layout where the domain-specific mathematical notation is being used. Cheers, Josh inline: notation-switch.gif On Nov 23, 2007, at 9:22 PM, Michael FIG wrote: Hi, Waldemar Kornewald [EMAIL PROTECTED] writes: Let's take the explanation from wikipedia: ... a mode is a distinct setting within a computer program ..., in which the same user input will produce perceived different results than it would in other settings Clearly, you need two different settings with two different interpretations of the same action. In our case, the first setting is math. The second setting is the programming language. If you introduce a different interpretation in a programming language then you introduce a mode because math is more common than that language. Math may be more common than that language, but for somebody writing a lot of code in that language, it may make more sense not to have modality within the language. We have three modes at work: 1) Math operator precedence, as taught to mathematics students. 2) Selector precedence, as taught to Smalltalk programmers. 3) The precedence of selectors that happen to look like math operators (#- #+ #* #/). You can unify modes 1 and 3 (which you are proposing), or modes 2 and 3 (which is the status quo, and what many other people in this debate are behind), but you cannot unify 1 and 2. No matter what the choice of unification is, somebody is going to be unhappy. This is why I suggested to refuse the default precedence for math-like selectors, and require parentheses to make the associativity explicit. In other words, the precedence of those selectors may be ambiguous because mathematicians are so fond of an implicit precedence that violates Smalltalk rules, so let's make it explicit. -- Michael FIG [EMAIL PROTECTED] //\ http://michael.fig.org/\// ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
