Larkin, Power BASIC cannot be THAT good:

My other favorite is documentation that describes the exact function that you need, but fails to tell you that it is 3 levels down in the

De gustibus non disputandum est. ;-)

Cheers! Rich

between ;-)

If there is a problem (there usually isn't and that can be taken care of with a resistor), it's no longer binary. Do you now what the word "definition" means?

subprograms,

horrible

Or whatever you'd like it to be.

between ;-)

I was joking - lighten up.

Why do you consider these optimisations scary. They are standard now in modern compilers and whilst a cooperative free software development team might take a while to get it correct they are on the right track. I don't approve of declaring register variables but apart from that ~OK.

Dead code elimination and determining paths where variables can be used before initialisation during compilation saves time. Some of the unreachable code lurking in a large project is often unintentional.

It isn't at all clear why. The sheer volume of data being moved and limited arithmetic means that the test you posted is very insensitive to the quality of code generation and entirely dominated by the performance of the memory subsystem. It is choking on external resources waiting for data all the time.

It would be interesting to see the x86 assembler code that Powerbasic has generated. I do not believe in magic.

JPEGLIB has reasonable documentation as does WFFT. Incidentally unless you are very interested in precise determination of very low frequencies you are barking up the wrong tree with a million sample FFT.

Regards, Martin Brown

graphics

gui

minimise

OK "."

What's scary is that they haven't done them yet, because the compiler isn't stable yet.

They are standard now in

"Unless" indeed.

John

Classic MS 'help'.

Photoshop's good for that one.

'Vital Industries' did real time broadcast quality NTSC video special effects with a Z80B in the mid '80s. 768 K of 12 bit DRAM for the video Luminance & Chroma signals. It processed one page, while displaying a second. It could also be used as a frame sync, to stabilize & synchronize external video that couldn't be genlocked to the studio timebase. The system filled a full relay rack and used 1,000 amps on the 5 volt rail.

^^^^ Really? Sounds interesting . . .

. . . Except that, no sane amount of hardware alongside a Z80 is going to use that much current. Methinks there was several orders of magnitude more processing power in MSI chips than the puny Z80! :-)

Tim

No. I had to repair the one at WACX in Orlando, Fl. a few times. It was built with early TI 4K * 1 SLOW DRAM that used multiple supply voltages. The entire system had one Z80B microprocessor. I looked at all 65 'C' sized pages of schematics to see for myself. The thing had

Most of the grunt work was done with lots of fast latches to route the data between the ADC to DRAM and from RAm to the DAC. Eight bits of luminance, and four bits chroma. Early and crude by today's standards but Vital was selling them faster than they could build them, and getting $250,000+ each.

graphics

Try it over serial link to a PS printer - it'll work. Of course you'll have to put something on the stack first.

Imagine you actually making sense.

does graphics

gui

minimise

Now that is a shame. I do not happen to have any postscript printers. Maybe i can try ghostscript, if i can figure how to run it as an interpreter application. Funny i do not remember finding "." as any kind of operator or function in postscript. Since you are much more familiar with postscript perhaps you can refer me to where in the PLRM is discussed.

"." isn't a predefined PostScript operator.

More generally, the only symbolic operators in PostScript are:

Everything else uses alphabetic names, e.g. the arithmetic operators are named add, sub, mul, and div, the relational operators are named eq, ne, lt, gt, le, and ge, and so on.

=20

That matches what i got from a very partial reading of the PLRM. I did pick up that there is some kind of name to user defined function association thing but it never became clear in my cursory browsing. Nor do i get the multiple stacks yet.

The main ones are the operand stack (i.e. "the stack"), and the dictionary stack.

The operand stack is reasonably obvious; values are pushed onto the stack, operators pop their arguments from the stack and push their results onto it.

The dictionary stack determines the scope of names. Whenever the interpreter needs to evaluate a name, it looks it up in the topmost dictionary on the dictionary stack. If the lookup fails, it tries the next one down, and so on until it either finds a match or it exhausts the stack (at which point you get an "undefined" error).

If you bind a name with "def", it is added to the topmost dictionary on the stack. At startup, there are two dictionaries on the stack: systemdict at the bottom and userdict at the top. The standard operators are defined in systemdict, which is read-only; userdict is where any user-defined bindings go (unless additional dictionaries are pushed onto the dictionary stack).

For complex functions, it's often simpler to start by pushing a new dictionary onto the stack so that you can associate names with parameters and intermediate results, rather than having to manipulate the operand stack explicitly with dup, index, roll, etc. Using a new dictionary ensures that you don't accidentally trash any bindings which were being used by the caller; you just pop it off when you're done with it.

The other important stacks are the VM stack (the save and restore operators save and restore the state of composite values such as arrays and dictionaries) and the graphics stack (gsave and grestore save and restore the state of the graphics engine, which allows elements of the page to be encapsulated so that any state changes within each element don't affect subsequent elements).

are

ne,

dictionary

stack,

next

systemdict

defined

Crickey, that is more like a list than a stack.

parameters

Well the insight in how to use the stacks is notably missing from the PLRM.