Prev: Can this be "refactored"? A simple 'wrapper function' to display MySQL data sets in tabular form
Next: The correct choice for implementation (was: A simple web client library)
From: Rob Warnock on 12 Mar 2010 08:03 Vassil Nikolov <vnikolov(a)pobox.com> wrote: +--------------- | rpw3(a)rpw3.org (Rob Warnock) said: | > Vassil Nikolov <vnikolov(a)pobox.com> wrote: | > +--------------- | > | I second this. As another view on it, consider the following | > | (possibly well-known) thought experiment: what does one do if one | > | has _only_ bare iron, but no software whatsoever ... | > +--------------- | | > Having been through quite a few bringups of various kinds of | > "bare iron", I would have to say that the style of low-level | > incremental bootstrapping you're talking about has been obsolete | > for at *least* four decades. | | > Instead, the easiest way to bring up bare iron is to load the | > absolute minimum binary boot loader you can get away with | > and then do *all* your software development by cross-compiling | > from a separate fully-loaded system and loading full kernel | > and/or filesystem images into your new platform. | | In any kind of practical situation, yes, certainly, both of the | above, but that means accessing software and breaks the constraint | imposed on the thought experiment. +--------------- To that, my only reply would be that the stated thought experiment is unrealistic/unhelpful for people planning on really developing hardware. We *do* have existing (cross-)software at this point; there's no point in spending time speculating otherwise.[1] These days, you should be debugging your boot loaders in simulation anyway, running a Verilog or VHDL model of your hardware and debugging the boot loader on *that*.[2] As I said, I've done my share of the old-style bringup/debugging of bare iron with minimal to no native tools available, and I *don't* want to have to do it that way ever again!! ;-} ;-} -Rob [1] Unless you're talking about pure "hobby" speculation, something like medieval role-playing where you don't permit sanitary toilets, running water, or refrigeration of food. But dysentery has never been one of my favorite games. :-{ YMMV. [2] Note that real hardware development companies [e.g., AMD, Intel, H-P, IBM, and in their say, MIPS, & SGI] actually simulate whole systems running a full operating system [Unix, Linux, Windows, whatever] -- at least through boot-up to a shell prompt and a few test apps -- *before* finalizing the CPU and system hardware design! ----- Rob Warnock <rpw3(a)rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
From: Hugh Aguilar on 12 Mar 2010 16:20 On Mar 11, 7:57 pm, Eli Barzilay <e...(a)barzilay.org> wrote: > PLT has one too, though I don't remember who did it. (Binding to some > jitting library is usually easy though -- at some point we had an LLVM > interface which would just generate LLVM code in text then pass it to > LLVM's jitter. In addition, PLT has certain features that makes it > easy to invoke some compiler from a macro, making the code generated > when the Scheme code compiles.) Please pardon my ignorance, but I don't know what "jitting" means. Is that Lisp parlance? > MrEd -- the GUI extension of MzScheme provides you with the usual > drawing primitives that you'd find in any such library. You can then > direct drawing to a window, a bitmap to be saved in an image file, or > to a postscript handle for printouts. On X, the drawing is handled by > Cairo (or if it isn't available, by plain X), so you don't need > specific Cairo bindings. I'm leaning toward learning PLT Scheme and using it for my slide-rule program. Afterward I will graduate to CCL or some other CL system. I will be able to make a more informed decision by then, hopefully. > (Postscript or PDF is probably much better than latex if you care > details like exact placement of text.) I don't know much about Postscript (or anything about PDF), but I do have some of the colored-series Postscript books in storage, so maybe I should dig them out and study them. You are probably right that Postscript would be a better choice. LaTeX is designed for writing books, not doing exacting work such as the face of a slide-rule. Thanks for the advice.
From: Helmut Eller on 12 Mar 2010 16:39 * Hugh Aguilar [2010-03-12 22:20+0100] writes: > On Mar 11, 7:57 pm, Eli Barzilay <e...(a)barzilay.org> wrote: >> PLT has one too, though I don't remember who did it. (Binding to some >> jitting library is usually easy though -- at some point we had an LLVM >> interface which would just generate LLVM code in text then pass it to >> LLVM's jitter. In addition, PLT has certain features that makes it >> easy to invoke some compiler from a macro, making the code generated >> when the Scheme code compiles.) > > Please pardon my ignorance, but I don't know what "jitting" means. Is > that Lisp parlance? It means "just in time compilation" or simply "runtime code generation". The term was popularized by Java VMs (may have been used by the Smalltalk community before that). See http://en.wikipedia.org/wiki/Just-in-time_compilation Helmut
From: Futu Ranon on 12 Mar 2010 16:43 On Fri, 12 Mar 2010 16:20:25 -0500, Hugh Aguilar <hughaguilar96(a)yahoo.com> wrote: > On Mar 11, 7:57 pm, Eli Barzilay <e...(a)barzilay.org> wrote: >> PLT has one too, though I don't remember who did it. (Binding to some >> jitting library is usually easy though -- at some point we had an LLVM >> interface which would just generate LLVM code in text then pass it to >> LLVM's jitter. In addition, PLT has certain features that makes it >> easy to invoke some compiler from a macro, making the code generated >> when the Scheme code compiles.) > > Please pardon my ignorance, but I don't know what "jitting" means. Is > that Lisp parlance? Just In Time compilation http://en.wikipedia.org/wiki/Just-in-time_compilation
From: Hugh Aguilar on 12 Mar 2010 19:32
On Mar 12, 2:39 pm, Helmut Eller <eller.hel...(a)gmail.com> wrote: > * Hugh Aguilar [2010-03-12 22:20+0100] writes: > > Please pardon my ignorance, but I don't know what "jitting" means. Is > > that Lisp parlance? > > It means "just in time compilation" or simply "runtime code generation". > The term was popularized by Java VMs (may have been used by the > Smalltalk community before that). I've heard of JIT, but didn't recognize the word as a verb. The trend these days is to have a back-end VM supporting JIT that can work with a variety of front-end languages. I don't really know anything about this technology. My experience with Forth hasn't exposed me to anything like that. Forth has threaded code, which is like a VM, but SwiftForth (what I mostly use) compiles to machine-code. Factor also. It is theoretically possible in Forth to compile code at run-time, but this is usually disallowed in commercial Forth systems. SwiftForth clobbers the compiler when it is making an executable to prevent SwiftForth customers from selling a Forth compiler in competition with SwiftForth. It is a rather crippling rule, but that is what Forth Inc. does. I have read that Lisp has a COMPILE function that will compile a list at run-time. Do your commercial Lisp systems clobber the COMPILE function when they are making an executable, similar to what SwiftForth does? On a related note, do Lisp and/or Scheme have quotations similar to Factor? Can you pass a chunk of compiled code to another function, and have that code access local variables in the originating function when it is executed by the other function? Can quotations be constructed at run-time, or do they have to be literally defined at compile-time? I don't really know anything about Lisp at this time, so if these are dumb questions and your answer is RTFM, I will understand. :-) |