Jazelle?

If you want high code density, you should learn Forth. It can support a complete Forth compiler in as little as 16 kB.

That's the Microsoft way of adding bloat on the baiss oh well we have lots oif RAM si it does not matter

Software design constructs that understand how the underlying mechanisms work and do what they need to do and no more causes less problems in the long run.

Also proper design means no "Oh dear need a faster CPU, because I don't understand why my software is slow" mantras as well

Well yes, but even so, down at microcontroller level, we are not normally operating with 2k of RAM!

No arguments there.

Apocryphal story: Gary Kildall (of CP/M fame) as a student holiday project rewrote a huge chunk of assembler....in FORTRAN. It was 10 times faster...

It not the language, its understanding how the code works.

But Forth _IS_ assembler, for it is based on the prior published art of the KDF9 computer architecture along with its drop, dup, data and return stacks.

Interpreting another assembly language must be the height of nuttiness!

Consider the solution of the quadratic equation expressed in a HLL ...

X = (-B + SQRT ( B**2 - 4*A*C))?2*A

... then consider what you have to do in Forth to achieve the same end. of pushing variables onto the stack and manipulating that stack to realise that Forth is, indeed, assembly language!

Which HLL uses "?" as division operator that has lower priority than "*"; actually, which HLL has a division operator with lower priority than "*"?

Anyway, this way of computing one of the solutions for a quadratic equation is bad because it introduces more numerical instability than is coming from the problem itself. Read more about how to do it better in

Yes. Forth has the benefits of assembly language (stability, performance) as well as some of the benefits of higher-level languages (in particular, portability), mitigating the drawbacks of assembly language (non-portability) and higher-level languages (instability for C, low performance for, e.g., Python).

- anton

The above reminds me of the debates we used to have (mid 1970s) about RPN vs algebraic pocket calculators.

With algebraic one had to use and keep track of parentheses and remember operator precedence rules. Yes, RPN at first feels unnatural, but with a little practice it became the preferred method for many of us.

The reality is that neither algebraic or RPN matches the way we would express the equation in class using pencil and paper. (view the following in a monospaced font) ______________ x = -b +- / b2 - 4ac \/ ----------- 2a

-Doug

Some of us still do... ATmegas with 2K RAM and 32K ROM (flash) are very popular (e.g. Arduino) ... And I dread to think how many of them (bigger and smaller) or PIC microcontrollers there are in a typical car these days...

Or microwave oven, fridge, coffee maker, etc.

I did a nice little project with the Atmel m48p a while back - 4K flash,

Gordon

Oh no look at the verry common AMTel AVR series

ATTiny 2323 128 bytes ATTiny 85 512 bytes

even the ATMega328 (as used in Arduino) only has 2k bytes.

I am pretty sure the figures for the Microchip PIC series are similar as are those for the 8051

Jazelle isn't supported on modern ARMs.

"The Cortex-A7 MPCore processor provides a trivial implementation of the Jazelle Extension. This means that the processor does not accelerate the execution of any bytecodes. In the trivial implementation of the Jazelle Extension: Jazelle state is not supported the BXJ instruction behaves as a BX instruction."

ditto A53. ARM1176JZF-S does support it, but it's a dead end.

Theo

A minor typo caused by typing with the shift key held down

And, yes, S/B (2*A) but neither critique answers the HLL versus assembler criticism.

Not relevant to demonsrtating the ease of use and built in syntax checking of a HLL compared to an assembler.

Very little commercial advantage in assembler; in fact just the opposite as far as productivity and reliabililty and maintainability go.

But this is not aboput a calculator; it is about a computer program laid out on paper, and one in which the syntax checking of the HLL compiler will root out mismatched parentheses in a way that no sytax checking in Forth would root out, for example, an extra DUP inserted into the assembly-like code.

Having worked on car systems (and railway brakes and signals) I doubt very much the appearance of PICs in anything other than CD players.

OK, thanks. The concept of byte code expansion into instruction streams in hardware was intriguing.

Those are RAM figures where code is typically not stored. Code is normally stored in Flash which all these devices have much more. TNP was thinking in terms of the rPi which has no on chip Flash... or RAM for that matter.

"S/B (2*A)"?

What "HLL vs. assembler criticism"?

If your example was an attempt to show the superiority of the Fortran notation over the Forth notation, then the fact that you made two errors in this one line was not a good testimonial for the Fortran way.

So you want to demonstrate the superiority of the Fortran notation with an example that no competent Fortran programmer will write in that way? And then you parenthesize it incorrectly, a mistake that will not be detected by "syntax checking".

Interestingly, in (from 1998) Gareth Alun Evans (any relation to you?) gave pretty much the same example (in BASIC syntax, though), and made the same parenthesis omission mistake. Not a testimonial for the qualities of infix syntax.

If you write the example in a numerically stable way, you get several smaller statements rather than a big one, more like most real programs, and the difference between infix and postfix becomes smaller. I guess that's why you choose this example; apparently it's hard to come up with another huge formula that many people can relate to. So even if the Fortran notation would be better for writing down one solution of a quadratic equation in a numerically unstable way (and the mistakes of you and Gareth Alun Evans are evidence against this thesis), that says little about the quality of that notation for real (and competently written) programs.

Anyway, here's a way to compute the roots (if they are real) without the numeric instability (you still have bad condition when bb/4 and ac cancel each other out, so you may want to compute that part with higher precision).

: compute-q { f: a f: b/2 f: c -- q } b/2 b/2 f* a c f* f- fsqrt b/2 f0< if fnegate then \ avoids cancelation by the F+ below b/2 f+ ;

: quadratic { f: a f: b f: c -- x1 x2 } a b f2/ c compute-q { f: q } q a f/ c q f/ ;

- anton

HLL can't find faulty use of parentheses unless you simply don't balance them.

Yes, Forth is often written that way. Very intriguing.

Why do you say Forth is based on any particular computer design? Forth emulates an abstract stack based CPU. The KDF9 is one of many which had been designed by the time Forth was invented.

is is a shame that Forth is a write only language