Richard wrote: I just had a long running argument with a clown that insisted that interpreted BASIC on a PCjr was as fast as compiled BASIC because the original BASIC compiler wasn't up to snuff in his opinion. I find the pages related to math and science are reasonable, but after that little encounter I'm a little more skeptical about Wiki. Colbert was right when he coined 'Wikiality'. Mike

Jay West wrote: It wasn't a theoretical environment in this case. It was the Wiki page for the PCjr, and the discussion page has the trail. For this discussion the PCjr has the same interpreted BASIC as the IBM PC. And there is no way on Earth that the interpreted BASIC on an IBM 5150 or PCjr is nearly as fast as compiled BASIC. In general I don't believe an interpreted language can beat a compiled language. Interpreting tokens or keywords is just far slower than compiled code, unless the compiler is severely broken. (Which I wouldn't call a fair comparison.) Except for Java VMs using just-in-time compiles (which makes it more of a compiler with a nice run-time environment), I can't think of any machine I've ever heard of where compiled was not faster overall. (Not talking about specific optimization, but rather the whole program.) Mike

Jay West wrote: I know of stack machines in theory only, so I'll take your word on it. None of the hardware I've used in the last 20 years (Z80, 6502, 6800, x86, PPC, etc.) would qualify as stack machines, and hence my lack of faith. :-) Mike

On 21 Oct 2006 at 12:07, Ray Arachelian wrote: ...and at some point, the stack overlows the L1 cache and degrades to memory-to-memory speed, no? While it's true that stack-based architectures can provide a lot of bang-for-the-buck, like single-accumulator machines, it's difficult to leverage parallelsim to improve performance. I'd venture that it's awfully difficult to design a stack machine that can compete with a 3-address architecture with a large register file, multiple pipelined functional units and instruction scheduling. Would you consider the Burroughs B5000 to be a stack machine? Cheers, Chuck

Chuck Guzis wrote: Except that it doesn't matter. They'll fall off out of the cache anyway, and the cache will now see a new area of memory, so the very early calls are no longer in cache, so you get a few cache misses. But the stuff the CPU's currently working on is almost always in cache. Once you return back to the beginning, you have another cache miss, and a reload. You can engineer the stack cache to work with this in mind. i.e. fetch lots and lots at once and don't have too many cache lines. The stack can and should have it's own separate cache, just like some arch's split data/code caches. As long as the cache part of it does lazy writes back to memory and is optimized to cache a stack rather than general memory, it'll fly. Multi-cores would work, each with their own stack caches. The odds are that two cores will never access the same stack, so it should work nicely. You can even dictate that this should never happen and let the OS deal with checking for the stack ranges to ensure it. Maybe. But unless the above machine uses register windows, or has some way to use the registers to pass data between functions. The expense is that using an L1 cache as a register file means that you need lots of L1 and to make it as fast as possible. At some point just having lots of registers doesn't help you if the compiled function doesn't use them. On context changes you always have to save all the registers to memory, so you'd lose on any interrupt. On the stack machine, you only have to flush the dirty cache lines, and you're done. Don't have to save very many registers at all! (Likely just PC, SP, and status registers.) It would also depend on the type of code you run there. Hand tuned assembly that almost never touches the stack would not benefit at all on a stack machine: the kind of stuff you'd do where you have a single purpose real time controller with very little RAM for example. But for generic C/C++/Pascal/OOP code, well designed stack architectures should run beautifully. The next big slowdown will be threading, as switching between threads will require flushing the stack (and all the other caches.) A multicore design can help eliminate a lot of the thread caused context switches, and besides, you'd have the same problem on any architecture there. IMHO, I think larger register windows would win over a stack machine however, especially when you have a function call chain where one fn passes it's operands to another fn which repeats this. Silicon wise, you'd spend about the same on the stack arch as you would on the register window arch. The flushes to memory would be less often on a register window arch, but would take longer to complete, while on the stack, there'd be more of them, but they'd be more spread out. I'm not familiar with that machine. What's it look like?

Chuck Guzis wrote: But remember FORTRAN uses direct addressing any machine that uses local memory like a stack machine has several hidden additions just to calculate your address. That is the price you pay for local adressing.

On 21 Oct 2006 at 16:00, Ray Arachelian wrote: You pay the price with context switches regardless at some point. You'll eat up cycles flushing the cache or storing registers, your choice. It's called global optimization. Real compilers do it. If it's truly a cache, and not just a queue for the stack, it has to use some algorithm based on history to determine what's kept in fast memory and what's not. Any time spent in compilation is one-off. Who cares how long it takes in the real world? Loop unrolling, register coloring, global optimization, variable renaming, vectorization (your stack machine works with vectors, doesn't it?) are all compile time overhead that no one really cares about, other than perhaps a few programmers. And that was the fatal weakness of the B5000 series. When it came down to crunching data, no one really cared if Algol-60 was the system language and the machine didn't have an assembler. The question is "Aside from the claims of elegance and similicity, how fast can you run Linpack?" To date, I've never seen a stack machine that can beat a traditional multi-address register architecture at that game. Have you? Stack machines have been with us at least since the early 60's. There must be a reason that when it comes to applications needing raw performance that no manufacturer adopts the model. Cheers, Chuck

dwight elvey wrote: A) Memory access time??? B) Code & data listing??? Like Mr Gates and his wonderfull Wind^H^H^H^H BASIC. PS, Does anybody have BYTE's small C benchmarks on line?

On 22 Oct 2006 at 11:21, dwight elvey wrote: ANY machine? I daresay the non-stack Cray C-90 could do considerably better than that! My point is that in the somewhat rarefied supercomputer world where computational performance is pretty much the entire game, not ONE machine deployed as far as I know was a stack machine. It would seem that if a stack machine had it all over memory-register systems performance-wise that you'd find at least a single instance of one in that market. ...and how does one efficiently do large vector arithmetic on a stack machine? Cheers, Chuck

On Oct 22, 2006, at 7:10 PM, dwight elvey wrote: RT2000...Do you mean the RTX2000, by Harris? Wow...Novix NC4000 and Harris RTX2000...damn fine Forth chips. I'd sure like to see a Verilog implementation of one of those designs. (well, less "see" and more "compile, burn into a config PROM, and hack on") -Dave -- Dave McGuire Cape Coral, FL

Chuck Guzis wrote: The same way one efficiently does large vector arithmetic on a non-stack machine.

Chuck Guzis wrote: Yes, and IBM went so far as to implement AltiVec, etc. A stack architecture is not mutually exclusive from a 3-address opcode, nor is a dedicated vector engine exclusive to a stack machine, anymore than an FPU, MMU or anything else. I believe you're confusing different features here. There is no marriage between a register file implementation and a 3-address instruction set architecture, nor any between a register file implementation and a vector unit, nor between a register window architecture and a 3-address ISA. Exactly. Just because it hasn't been done in the past doesn't mean that a) it can't be done, or b) if implemented properly it won't be faster running C/C++ code over a similar architecture that isn't a stack machine. Nor does it mean that the first implementation of such a thing will be faster than current technology any more than the first RISC's were that much more substantially faster than previous CISC's. It doesn't actually. Nor would a nascent stack machine built today be necessarily much faster than its peers - for the first iterations! Example: For a lot of things a 68040 running at 40Mhz was a lot faster than a 40Mhz SPARC v7. But after a while as the SPARC ISA progressed, you saw better and better implementations that left the Motorola line in the dust. Let's take this analogy further, to say software floating point routines VS hardware FPU's: The one and only thing an FPU buys you is fast floating point math. If you look at the early implementations of Intel's, you'll find references that say software floating point routines on an 8Mhz 68000 were faster. You can't say that any more of software implemented 680x0 floating point instructions versus, the FPU of an intel chip of a P4. Over time, things improve. Mostly incrementally, but they do improve. Expand it a bit out of FPU's: Nor can you say that an FPU is great or poor at vector processing. A mature FPU will run rings around a nascent vector until, but give it a few generations of design and you'll find the now mature vector units will do much better at vector processing than current FPU's. What I'm saying is that I believe you're comparing oranges and pineapples here. They do completely different things. Up until recently you didn't see vector units inside microprocessors. You do now because they're useful and more importantly because they're becoming practical to implement. In the early days you didn't see FPU's or MMU's, nor SIMD's, nor multiple cores built into the microprocessors. You do now. The various technologies involved do different things and speed up processing in different areas of code, (or in the case of an MMU provide memory protection and virtual memory capabilities). Whether a specific CPU implementation uses a two address or three address ISA is independent of how it implements its register access, and is independent of how it implements a vector unit, or an FPU. Whether your architecture has 2 or 3 addressing depends on only one thing: the guy that mapped out the bits of the opcodes and operands to the opcode decode unit. Did he have enough bits for 3 operands, or did he give up and use 2 like most folks? There's a lot you can do with a 64 bit wide instruction that you can't with a 32 or 16 - (unless you have variable sized opcodes and think that the guys using your chip will benefit from what you put in there.) You don't have to take my word for it. Here's the proof! While the SPARC ISA is not a stack machine, it's based on the next closest thing: register windows, which behave identically to a stack architecture machine up until you have to access main memory. Take a look at this example of SPARC assembly code: ld [%l2],%o0 add %l1,%o0,%l1 add %l2,4,%l2 inc %l0 ba loop See those two ADD instructions? How many addresses do they use? Why 3! Would you say that machines with register windows are faster than those without? How far off is a register window from a stack? Don't answer that, let's look at an actual stack machine: Here's a direct quote from the AT&T 92010 Hobbit CPU manual as used in the Eo 440/880's: "True three-operand (triadic) instructions are not provided. However, instruction encoding that provide two source operands and store the full 32-bit result in the accumulator are provided. This instruction is called a two-and-a-half-operand instruction. "For example, the mnemonic for an addition instruction is ADD3, while a two- operand (dyadic) addition is ADD. For this instruction, the two source operands are added and the full 32-bit result is stored in the accumulator." ... Ok, so far so good, but what exactly is the accumulator, sounds like a register, right? Not quite! "1.4.3 Integer Accumulator** The integer accumulator is not an actual hardware register. It is the word in memory above the word addressed by the current stack pointer (CSP). The CSP is either the stack pointer (SP) or the interrupt stack pointer (ISP) as determined by the program status word (PSW). "The integer accumulator normally resides on-chip in the stack cache, but it may be off-chip if the SP = MSP or CSP = ISP." ... So there you have it, a 3 register operation on a stack machine. Ok, granted the third register isn't addressable like the others, but none the less, it is on the stack, just like the rest of the other operands. Why did they do it that way? Same reason everyone does stupid things (at least from some points of view): Compromise! They didn't think it was important enough to expand the ISA for it - so they went a bit cheaper to save on cost fully supporting it. This is because the ISA doesn't have room in the opcode definition for 3 register indexes. But either way, it's still in there. There is absolutely nothing stopping anyone from building an ISA with 3-addresses as you call them, or 3 triadic operands as AT&T calls them. Wow! What a miracle! A Stack machine that takes 3 addresses! Why does this machine suck you ask? Simple, it only has enough room for 64 stack entries in the cache. It doesn't have an FPU. It doesn't have a vector unit. It has only a single core, at the fastest they've built ran at 32MHz. But you know what, for its day and age, and considering that it was meant to be used in portable machines such as PDA's, it compared very nicely to other CPU's of the era. If you look at the size of it's internal cache, it was certainly on par with low end 32 bit CPU's. What else did it feature? MMU with dual 32 entry TLB's 3-stage instruction pipeline A 32 bit integer unit. Tagged math for OOP coding. Prefetch instructions for on demand prefetching Branch prediction and branch folding Instruction Tracing Vector base for interrupts so that you can have multiple processes. Kernel/User mode 7-level interrupt model like the 68000 (NMI + 6 IRQ's) 3K instruction cache implemented as a 3-way set associative cache 256 byte stack cache big endian/little endian byte ordering Was it a CISC or RISC? Neither, it was something in between, they called it a CRISP ISA. But this was not because it's a stack machine, but rather because it didn't use a fixed opcode size. Like CISC machines it used a variable opcode size, and like RISC machines it had lots of registers. Granted most of those registers were on the stack. If you were to build a modern multi-core 64 bit version of the Hobbit CPU, add an FPU and vector unit and large enough split caches, you'd find it would work quite nicely. But was it fast you ask? To answer your question get your hands on two machines running the PenPoint OS. Two machines from the 1992 era! An AT&T Eo 440 and an IBM Thinkpad 730 The TP730 used a 486SL/33 (no fpu), 8MB of RAM and optional hard drives. The Eo 440 used the Hobbit 92010 running at 20Mhz, and the Eo 880 ran at 30Mhz. They had 4MB of RAM and optional hard drives. Wanna guess which was faster? I'll give you a hint, it's the machine that has the famous deathstar logo on it! Yes, even the low end 440 running at *20Mhz* with *HALF* the RAM outruns the Thinkpad! Now, that's comparing apples to oranges, sure, since they're different machines with different motherboards and chips, but sorry, I've no other way to compare them. That said, if you open up an Eo, you'll find mostly standard PC hardware beyond the AT&T Hobbit chips. And they ran the same operating system: penpoint. Yet, if you compare something very basic such as the response time of the time when it refreshes the screen, (I don't mean just bitblit drawing, but rather when it performed CPU intensive operations), the Eo outran it. In fact, it outran it in every operation I tried including the crappy handwriting recognition. Is it possible that a stack machine could actually fast? Wow! We must be in an alternate universe or something! http://pencomputing.com/old_pcm_website/PCM_7/review_thinkpad_730te.html http://www.bebox.nu/history.php?s=history/eo http://www.quepublishing.com/articles/article.asp?p=481859&seqNum=15&am…

Chuck Guzis wrote: Indeed! Somehow you started out with the "It has to have a 3-address to be fast" and "how would you do vector math on a stack machine" argument, and now you change your song when the very thing I've pointed to showed you a stack architecture that uses a 3-address mode? And one that beats out a very similar other machine at that! Nice try! I suppose this kind of cut and run tactic must work on some folks. ;-) Speaking of vectors, have you heard about http://www.sun.com/processors/vis/ - yeah, that's an extension to the UltraSPARC line. :-D I'm sorry, how's that again? Who spoke of emulation? :-) Ask supercomputer designers, I'm not one of them, and no familiar with what's out there. It doesn't matter that much anyway since a lot of supercomputers today are built from common off the shelf microcomputer CPU's. That said, I just showed you two very similar 32 bit architectures of the same era that ran the very same OS and were meant for the same purpose: PDA's. They aren't mainframes or supercomputers, they're micros. They were built to run the same OS and have very similar hardware, right down to the RF based digitizer tablet. The type of computer doesn't matter. The basic principles of all computers have a lot in common. What you see on supercomputers, you'll see on microcomputers within reason. Even today, you see multi-core CPU machines that were you to compare with past supercomputers, would pass for such to some extent. They all have ALU's, FPU's, MMU's, RAM, disks, networking, buses, multiple CPU's, I/O devices, etc. They're all computers. You've conveniently ignored the data point where a stack machine beat out a very similar non-stack machine, and retreated to the supercomputer realm. This isn't analogous to the some species of well written interpreter beat some species of poorly implemented compilers. These two machines are very similar and run the same OS. Yet, one beat out the other. You can speak of performance in one area or another, but claiming that a machine that lacks a vector unit, but uses a stack architecture is slower than a machine with a vector unit and uses a register file is a very poor argument. There's nothing to prevent you from building a stack machine that has a vector unit. Of course, for vector math, a vector unit speeds things up, but what if you don't need to do vector math? What if your benchmark is deep recursion, not iteration? Of course a 3-address Instruction Set easier to write a compiler for than 2-address instruction set. But then, in the same way, so is a stack machine's ISA a lot easier to write an optimizing compiler than on a machine that has a plain register file and no register windows. And yes, having a vector unit makes code that uses it much faster, as does having an FPU make floating point code faster. Back to the PenPoint machines: The one machine with the stack architecture outperformed the one without. The one with the stack architecture does infact have the ability to use 3 operands. One of them was implied, but also lives on the stack. It met ALL of your requirements save the supercomputer one, which I find specious. I'll address that in the very next paragraph: Another CPU I've mentioned, the SPARC, is similar to a stack machine in it's use of register windows, and does use 3 operands in its opcodes. In fact SPARC chips are used in supercomputers: Fujitsu PRIMEPOWER HPC2500. So I'm sure you'll find a reason as to why this doesn't fit your request to be shown a stack architecture based supercomputer, and you'd be right as the SPARC isn't a stack architecture. But, in regards to this discussion, it sure quacks like a duck and has the same kinds of feathers. :-) A canard perhaps? 8^) This isn't to say that every stack machine architecture will beat every other non-stack architecture at all jobs. The assertion here is only that a that a well designed stack machine will outperform a well designed non-stack machine with similar other features in one specific area: function calls. Period. I don't believe that I've asserted anything else in this discussion, and I believe that whether on a supercomputer, mainframe, mini, microprocessor, or microcontroller the above statement will hold.

Andy Holt wrote: Yes, and quite ironically, the thing that did in self-modifying code was the cache. Ok, well pipelining did help drive that nail in the coffin of self modifying code as well. :-) There are some interesting optimizations that you can do with self modifying code that we just don't have today, but overall, the benefits of caches and pipelines outweigh them. Exactly. Sure, even today when you have a specific application in a device that's very short on memory, let alone stacks, then you have no choice but to write code that can't use stacks. So a stack architecture would be useless there. Writing that code would also be an insane braint wisting effort too. This may be shocking, but I don't personally care about that much about stack machines. :-) No, seriously, the thing that got my goat was the fuzzy thinking around how one would have a magically fast machine if you had a 3-address ISA and how it's important to do vectors and how a stack machine can't possibly do vectors, and that unless a supercomputer has it, it's just not important somehow. Stuff like this is just pure superstition. (I'd normally use stronger language here, but I didn't want to get too impolite.) :-D For my own needs, I buy whatever reasonably fast machine I can afford depending on the need. For day to day use, I've zero use for a vector engine, and zero use for a stack machine. It might be fun to have a nice fast graphics card, which of course would make great use of a GPU that did vectors, but, you know what, I almost don't bother playing modern games at all. I may fire up MAME and play PacMan or Defender until I'm bored, but that's about it. I did go and buy a Playstation 2 back in the day, but after about 6 hours of play, it's been gathering dust for the last 3 years. GPU wise, I might make an exception for OpenCroquet, but beyond that, vector engines or GPU's aren't all useful to me at all. For the stuff that I do, I don't require register windows, stack machines, vector units, GPU's. FPU's are nice, but I don't find myself doing very much requiring them. If they're included in the box I buy, great! Wonderful! Won't make that much of a difference. On the other hand, if I'm recommending a machine professionally, I certainly take into account what their code does, how it works, what resources it needs, and what can make it run faster, and pick accordingly to those specs and their budget. Yes, I do have a very nice set of SPARC and UltraSPARC machines, as well as an Indy and HP-PA, and Eo's, various Macs, and a bunch of beautiful classic 8-bit machines, but day to day, stacks don't make a bit of difference to me. :-)

On 23 Oct 2006 at 13:35, Ray Arachelian wrote: An ad hominem attack? Shame! Well, it's been fun, but I'm getting tired of this. Let's cut to the chase: Define "well designed"; define "similar". I'm not at all convinced. But, what defines "performance"? How about "work performed in a given period of time"? Could we agree that two machines with roughly the same gate count applied in the same way and speed and clock rate are "similar"? But I doubt that two such examples even exist. So to "outperform" would be one such machine producing more useful results per unit time than another, no? Where does the function call fit into this picture of getting results? Answer: it doesn't. By and large it's a bit of semantic fluff--an attempt to re-use code that otherwise might be inlined. Unnecessary in the grand scheme of things--and a hindrance to performance and code optimization. While a stack architecture *might* be better than others in the area of function calls, I'm not at all convinced that it is. The comparison just has too many subjective aspects. Almost any instruction is a bit of fluff in the grand view--as long as you have at least one to execute. I've certainly used machines without stacks or CALL instructions and never really missed them for felt that they would make a substantial contribution to performance. Cheers, Chuck

Chuck Guzis wrote: YES! From what I've read here, it's a beauty! http://en.wikipedia.org/wiki/Burroughs_B5000#Stack_architecture

Michael B. Brutman wrote: Well it is hard view them as general purpose computers, more designed for simple character handleing or simple control. The x86 I still am wondering is a 8080 hacked to 16 bits or not?

Michael wrote... When I said "stack machine" I wasn't referring to the cpu architecture. I was referring to the software design of the interpreter. Hence, I most definitely was referring to platforms like the 6502, 6800, 68000, intel, etc. And yes, I personally have seen a basic runtime interpreter that was implemented as a "stack machine" that was faster than compiled code on the same platform. As a matter of fact, this was on the 68000 at the time. Jay

Jim wrote.... Nah, it wasn't. It's just that (as has been pointed out here), pseudo code that is well designed can sometimes be executed in less instructions than a compiler generates for the equivalent task. Jay

Jim wrote... You've obviously never written an interpreter have you. If you'd read what some of the previous people have posted on this topic, you'd get a clue. Instead, I'm left thinking you chose to ignore any input that isn't what you want to hear. Jay

Jay West wrote: I haven't read a single statement that explains how native, compiled code could possibly be beaten by an interpreter. If I want to evaluate the expression "a := a + b" on an x86 machine, where a and b are variables in memory, I would expect a compiler to produce the following: mov bx,b add a,bx You can't tell me any interpreter could possibly beat that. As der mouse said, even if the interpreter produced exactly the same code, there is the overhead of the interpreter itself. -- Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/ Help our electronic games project: http://www.mobygames.com/ Or check out some trippy MindCandy at http://www.mindcandydvd.com/ A child borne of the home computer wars: http://trixter.wordpress.com/

Chuck Guzis wrote: Ah, but that is an implementation difference on the way an interpreter and a compiler might handle strings. If the compiler used a length descriptor strings then the implementations would be equivalent, and the compiler should have the upper hand? The topic/question originally started as 'A compiler generally wins, given all other things being equal'. One of the problems with the discussion is that if you include the runtime for the compiler, then you basically can match anything an interpreter can do at run time. So the whole discussion might be moot, and might just come down to 'my specific implementation of such and such is better than yours.' Mike

Chuck Guzis wrote: (snip) (snip) As you demonstrated yourself, the compiler. Which is still my point. I accept that there have been some truly crappy compilers where a well-written interpreter was able to beat them in execution speed. But what I take offense to is the notion of some people here that the interpreter was *so* cleverly written that it could beat *any* compiler for that language, which is just BS. -- Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/ Help our electronic games project: http://www.mobygames.com/ Or check out some trippy MindCandy at http://www.mindcandydvd.com/ A child borne of the home computer wars: http://trixter.wordpress.com/

Well, yes. (And an interpreted implementation could be stupid too.) I don't think anyone has said that a stupid compiled implementation can't be beat by a smart interpreter. What I'm having trouble with is the claim that some interpreters can beat compiled code in general, rather than specific (and stupid) compilers' output. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Sean Conner wrote: What was it? -- Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/ Help our electronic games project: http://www.mobygames.com/ Or check out some trippy MindCandy at http://www.mindcandydvd.com/ A child borne of the home computer wars: http://trixter.wordpress.com/

Jay West wrote: With all due respect, how would you know if somebody had written or never written an interpreter? Jim used strong language to express his skepticism. I don't think that should open the door to telling people to get a clue. We're subscribers to this list, so I assumed that meant we had somewhat of a clue. You're not dealing with high school students here. Mike

Jim Leonard wrote: Microsoft QuickBASIC 4.5. Try it with "Gorillas". Peace... Sridhar

Jim Leonard wrote: QuickBASIC 4.5. Compiled programs compiled by QuickBASIC 4.5 is slower than interpreted programs run under the QuickBASIC 4.5 interpreter. Peace... Sridhar

Jim Leonard wrote: It could be that it is using 32 bit ints under FORTRAN as a default. Looking at FORTRAN IV for the PDP-8 you have 24 bit ints standard so all you integer math is a call to suboutines. Some verions of FORTRAN for the PDP 11 was threaded code too.

At 11:00 AM 10/22/2006 Michael B. Brutman wrote: And if a DVD shows a four hour movie then a CD should be able to do the same thing

I'm having trouble thinking of an example of such a "something". Can you cite one? It'd help me understand. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

this thread is becomming tedious, and suffused with more noise than information. Think about the case, for example, where the primatives being modeled are large and complex. So, the overhead of the interpreter is swamped by the actual processing. A compiler (or native code) has no advantage in that case becuase (let's say) 90% of the processing is done inside the primative. I think this whole 'concept' is too broad and generic for a simple description. Just trust those who have written compilers and interpreters. Interpreters can be suprising fast and can be more appropriate choices than a compiler. Nothing is black and white. -brad

----- Original Message ----- From: "Bob" <zzzzz at sbcglobal.netTo: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.orgSent: Monday, October 23, 2006 2:28 PM Subject: Re: Compilers vs. Interpreters modifiable code enviroment. Many years ago, I programmed in a language called CREDIT, running on Philips P6000 series. This more-or-less interpreted language had some remarkable features. It had a kernel handling the (1 byte) opcodes. For data, 16 blocks (IIRC) were available, but redefinition was allowed. For each data item, max 16 per block, a table was kept specifying the peculiarities of each item. So, a simple MOVE would demand 3 bytes : 1 for the opcode, 1 for the source and 1 for the destination. A MOVE between two indexed items would take 5 bytes, as two bytes were needed for the indexes (1 byte each). This would make it extremely easy to modify the instructions, as you didnt need to know much about the data. Also, the resulting code was so compact, that we could accommodate a back-office routine for entering financial data (30-40 different record types), plus a routine for transmitting the data via a 3270 connection, within 32K bytes Nico

On Sat, 21 Oct 2006, Jim Leonard wrote: That's not that hard to believe. There were some definite problems with some of the early Microsoft compilers. Bob Wallace, who wrote their Pascal compiler, advised me to never use the runtime library.

Chuck wrote.... Exactly my point Chuck, thanks :) Jay

On Fri, 20 Oct 2006, Michael B. Brutman wrote: It all depends on how poorly optimized the code is for BASCOM. Were you working with integers, or with the default single precision float?

A simple "Sieve of Erastothanes" benchmark ran faster in 5150 interpreted BASIC than it did with Microsoft's original PC FORTRAN compiler.

On Sat, 21 Oct 2006, Michael B. Brutman wrote: I don't want to be accused of defending the PC architecture nor the MS BASIC interpreter. It was VERY broken. But, ... it was still usable for teaching beginning FORTRAN at a very cheap cost. -- Grumpy Ol' Fred cisin at xenosoft.com

Hi The main issue for drive is magnetic fields. Surprisingly, the write is more sensative than the read to stray field. This is because during writes, general bias one way or the other effects the amplitude of the signal. Reading is looking for edges and bias has little effect. Actually erasing would take a very strong magnetic field from any distance to the drive( inverse square law ). Dwight _________________________________________________________________ Add a Yahoo! contact to Windows Live Messenger for a chance to win a free trip! http://www.imagine-windowslive.com/minisites/yahoo/default.aspx?locale=en-u…