general question about riscos.

dummy% = EVAL(“FNassign(“+name$+”,”+value$+”)”)
DEF FNassign(RETURN n, v) : n = v : = 0

:)

When I mentioned that Trellis uses EVAL earlier, I was going to say I considered adding a similar construct to that but decided against it – I’ve long since forgotten why I didn’t bother.

The reason I didn’t mention it earlier, though, was because I’d forgotten exactly how to do it – but it was instantly recognisable from those two lines.

(context) I may be wrong

You’re not, and it’s sometimes really a problem…

I was wondering about the feasibility of creating a (braindead) BASIC compiler of my own, as it shouldn’t be too difficult to just “interpret BASIC, spit some code”. The result would probably suck, but it would be a beginning.

For the basic things, it’s ‘doable’. But for calculated gotos, evals and libraries, it’s another problem. Ohhhhh, exactly what ABC can’t do :)

Anyway, there is BBC_C. Very cool application.
http://www.martinkd.freeuk.com/bbc_c.html

As such, the compiler would either need to be modified to tag and record every single variable name, or this functionality would be omitted. I understand why EVAL is not supported…

Yep, when Eval is used, you must keep reference of where are each variables. Always the same with integrated interpreters.

Might I suggest you look at alternative implementations? There are big complicated professional spreadsheets written in languages that don’t even have an EVAL function. C, C++, etc.

Funny :)
And how do you make evaluations in C? With parsing and calculation. Exact definition of an interpreter.
To implement complex evaluation of user expressions, most of the time we embed a complete interpreter (more future proof).

Why? Part of compiling something is to resolve the references to variables and functions to locations in memory.

Not for him… for the eval/integrated-interpreter needs.

A fairly complete BASIC interpreter
Knowledge of all of the available variables, by name
Ditto functions
Ability to call functions and use the result
Maybe some other stuff I’ve forgotten

Yes, yes, yes. But the real problem is not here. The problem is the level of interaction needed/wanted between Eval and the other parts of the code. If you just get access to variables, hum, it’s not much difficult or impossible to make… than to embed an ASM compiler in BBC Basic.

If you want to call functions, that’s a bit different, but nothing impossible. You call native code, and this code return to you later. You is not your interpreted code, but the interpreter itself. That’s what you do when you call a SWI from an interpreter.

Absolutely nothing that cant be done, even if, and I tell it from the beginning, a full version of Eval is not needed and – IMHO – too much work for nothing. The problem is that Eval is in BBC Basic. So not to have it in ABC is a problem. Now, there are also ways to go the other direction: to have a Basic without all ABC cant do or don’t want to do. Why not.

switch

Oups typo. No everybody will now I almost never use switch :)

This is the power of a compiler. It can spot that a+10 is an assignment and do something like ADD Rx, Rx, #10 as opposed to ADD Rx, Rx, Ry for the a+b version.

Of course. Basically to go from code to opcode needs to compile the code for a VM. Problem: since most interpreters are made in C, with switch, you cannot implement a lot of opcodes. So you break your statements in small parts. To use an array of pointers to functions (or, as in BBC Basic, a branch table) solves this problem. Then you can play.

But there are other problems with interpreters. The worst one is complex interaction (coming from inside – interpreted threads, timers, etc. – or from outside – callbacks, events, etc.). Basically, you let the user deal with this (a la BBC Basic) or you implement your own event manager. I’m here today with my engine. Sometimes I regret the 80’s when they were almost no interaction between the interpreter and other parts of the system.

I’m afraid I find the idea of a spreadsheet evaluating expressions with internal knowledge of the structure of the software itself to be………horrifying.

You don’t. As with any interpreter, input is completely filtered. You can’t tell ‘call this function’ or ‘read this variable’. You say ‘read cell x,y’ and Basic will change this at runtime, before eval, and change it again for you, when you want to modify the expression (an interpreter before the interpreter). It’s not yet secure (it was just for fun), but it can be. Anyway it’s not less secure than any buffer overflow. Always the same problem of boundaries, but here much easier to exploit.

But I’m agree: to know you’ll have to deal with unattended input is scary.

I believe that there are JIT compilers that can adjust themselves on the go, eliminating optimizations that it finds to be not worth the effort.

Mainly for speed issue with JIT compilation itself :) But some of them can also invert some flows when needed. If an ‘if expr’ is most of the time wrong, why not make an ‘if not expr’. Then you don’t break the pipeline any more.

Yup. It optimised it down to one instruction.

Norcroft compiler is really fantastic, but suffers of problems with support of new instructions (especially floating point). That’s why I still have hesitations between C, ASM or something else for the first non private implementation of my toy engine. I could go much further with ASM, but I can’t make so much optimisations. On the other hand, optimisations are mainly in the ‘code to pcode converter’. But if I use ASM, I could simply convert to ASM… and get a compiler. I’m damned :)

I made two type of things around programming languages in my career: xxx2C interpreters and embedded interpreters. With the first one, you get speed but loose some ability to debug (and so ease of use). So it’s important to have an interpreter identical to the compiler. What ABC is not (and what VB was).

On the other hand, with an interpreter you can go much further on management of flows: complex evaluation at runtime (basically, with append, eval or library, it’s modification of code at runtime); not to be confused with self modifying code that permits, with analytic, to change an expression for a better one at runtime (if vs if not) or to break the flow by inserting a goto (for example to simulate threading); to invert the clock is interesting too for debugging; and of course, management of resources is easier (and portability a bit better too). But it’s slow :)

Of course, most people will say you don’t need that. But the hidden reason is that, in the IT market, an interpreter does not have the right to be more powerful or flexible than a compiler.

Now, what should I do… pfff

(sorry for all the mistakes. I’m a bit tired).

does the compiler see things at function/block level instead of just line by line?

You bet it does. What constitutes a block, whether blocks have their own scope, and whether blocks can be nested depends on the language. A block’s local variables will be compiled to offsets on the stack. The locals of enclosing blocks will constitute an environment, usually a datastructure held in the heap because they will be needed for the lifetime of the enclosing block. C is much simpler in this respect because functions are not nestable; there is no need to distinguish between functions and closures in this case.
Consider

function add (x)
   return function (y) return x + y end
end

So it’s important to have an interpreter identical to the compiler. What ABC is not (and what VB was).

http://www.heyrick.co.uk/software/vbopti.html

That pertains to P-code. Try it with native executable and you will find a completely different set of results. The interpreter and compiler are similar enough that they will build the same code; but their behaviours are not identical.

This is, of course, somewhat academic since VB is not only the same company, it’s the same product.
Same cannot be said of BBC BASIC and ABC.

Same cannot be said of BBC BASIC and ABC.

The last time I touched ABC was back in 1988, if I remember correctly there were all kinds of caveats to it, to the point it required your BASIC code to pretty much be written with it in mind. I steered clear of it from then on.

It’s probably easily fixable, it could for example include the BASIC module code and fall-back to interpret known differences. I’m not sure why Acorn didn’t do that in the first place, code size possibly.

A quick Google turned up the User Guide which details the discrepancies on p15, starting with the following statement:

In an ideal world, it would be possible to have complete source and object compatibility between the BASIC interpreter and the ABC compiler. Unfortunately, this is not the case. There are certain small differences between the syntax for some instructions, as well as in the output generated. An existing program may, therefore, need some minor modification before compilation.

Some of these differences are inherent in the execution of compiled or interpreted code. Others are deliberately implemented to improve the performance of the compiled code – since the compiler is primarily intended as a development tool, not just a new way to run existing programs.

Re: Rick’s site:

If ((ProcOne = True) And (ProcTwo = True)) Then…
Most languages will use short-circuit logic, that if the ProcOne function does not return True then the ProcTwo function won’t even be executed.
But not VB. Oh no, VB will execute both procedures regardless of whether or not there is any sanity to it.

For what it’s worth, “AndAlso” instead of “And” will make it only evaluate the left side.

aaaaa

aaaaa

http://www.heyrick.co.uk/software/vbopti.html
That pertains to P-code. Try it with native executable and you will find a completely different set of results. The interpreter and compiler are similar enough that they will build the same code; but their behaviours are not identical.

That’s why the two can be very interesting. Or not. I’m still between the two. More interpreting in the compiler, or simpler ways to make native code in the interpreter. We could for example think of tasks_functions for the interpreter, with limited functionalities (a single array of integers, integers calculations only) and all will be compiled at runtime. tasks_functions could even run async. Needs here an internal event handler (that could be used too for wimp events).

tasks_functions could be separate processes. If they crash, the address of the error will permit to know (by compiling again the source code), to know where the error occurs (which line). It’s just an idea. My problem is that I know more interpreter than compilers, but would like also to address the HPC market (with client/server technology to make nodes working together).

Native code is less easy to manipulate for end users (developers).
Interpreted code in ASM is not easy for me and difficult to maintain.
Interpreted code in C is not fast enough with current Norcroft C (no FPU, no NEON).
I have prototypes, they work, but don’t know which method to adopt.
Perhaps Charm?

That statement implies its distinct from BASIC, should be developed for specifically and not be used to just speed up BASIC without careful planning and awareness of the differences.

Exactly my point.

where the system can check type and a certain number of base things about the program/module at runtime without having its source or having been compiled/linked with these information.

Of course, but you do all the work at compile time. The compiler should then put all the data necessary, or that will be necessary. That’s a lot of work, but not very different than to implement debugging instructions or code to break code in small parts (to emulate PMT in a CMT system).

aaaaa

For what it’s worth, “AndAlso” instead of “And” will make it only evaluate the left side.

VisualBasic.Net != VisualBasic.

The two are even less related than BBC BASIC and ABC.

That BBC BASIC does not have AND and OR lazy in the second argument is a fundamental mistake and can lead to nasty programming errors. C also kludges Boolean values as integers but at least it gets the semantics of && and || right.

Debug instruction will be compiler specific, and most likely will not be useable from other compiler

The same with an integrated interpreter.

That BBC BASIC does not have AND and OR lazy in the second argument is a fundamental mistake and can lead to nasty programming errors. C also kludges Boolean values

BBC BASIC doesn’t kludge the boolean operators – it doesn’t have any. AND and OR are bitwise operators so the right hand side is always relevant. If you program knowing that there’s no problem.

This topic maybe getting a bit stale now, but let’s throw a few chunks of meat to the lions. ;-)

No-one has yet mentioned RiscBASIC form Silicon Vision. It was always considered a far more compatible and faster compiler than ABC, although I had no experience with it. It was never 32-bitted and they have long left the scene, but its existence makes the case that a far better compiler is possible than what we have.

No note has been made of the size of compiled ABC code. For understandable reasons, the bloat is huge.

You do not have to actually include the BASIC interpreter if you were contemplating it for EVAL. A BASIC module is alway resident, and if Edit has been run, Edit$Tokenise will give you the address of the MATCH routine and just before it the EXPR routine which is what EVAL uses. There are other way to achieve this.

For David’s purpose, calling EVAL this way is no good, anyway. ABC uses floating point numbers in the FPA formats; BASIC EVAL will be expecting 5-byte floats.

I would rather say that all programming languages have to cope with Booleans in one way or another. And all languages need to have some form of laziness to avoid evaluations in branches not taken. In BBC BASIC such laziness can only be implemented using IF .. THEN .. ELSE or CASE structure (let us not mention GOSUB in polite society).

I was wondering about the feasibility of creating a (braindead) BASIC compiler of my own, as it shouldn’t be too difficult to just “interpret BASIC, spit some code”. The result would probably suck, but it would be a beginning.

I think I have a couple of peoples’ attempts at doing this from way back. They worked but were severely limited.

dummy% = EVAL(“FNassign(“+name$+”,”+value$+”)”)
DEF FNassign(RETURN n, v) : n = v : = 0

I have been using one variant or other of this for a very long time, but a compiler cannot use it. As another illustration of the use of a keyword being both simpler, faster and more flexible than a routine, Basalt does assignement to a named variable with a pseudo-variable syntax:

EVAL(varname$)=value

This does integer, float or string, not just numeric. Internally it is just a simple call to EXPR, with no faffing around.

No-one has yet mentioned RiscBASIC form Silicon Vision. It was always considered a far more compatible and faster compiler than ABC, although I had no experience with it.

I had it. And quite possibly still do, sitting in a box somewhere in the loft, or in the darkest depths of the Mysterious Cupboard of Ultimate Doom (which is a couple of feet to my right).

I can’t remember much about its specifics, but like ABC it obviously suffered limitations compared with BBC BASIC. The lack of EVAL, for example (and on-topic for a large part of this thread), should be obvious. :)

As you said a couple of days ago for ABC, I tried a number of programs with it – and the results were marginal at best, though ISTR most were slower. I believe a big part of the reason for that is that these were BASIC programs written as BASIC programs, and not with the compiler in mind: Just as Jon pointed out with ABC, if you were using it you would have to write your programs with it in mind, rather than as you might if you were just writing a BBC BASIC program.

The result was that I never actually used it for anything.

EVAL(varname$)=value

Nice.

aaaaa

aaaaa

VisualBasic.Net != VisualBasic.
The two are even less related than BBC BASIC and ABC.

Sorry; I didn’t read the page closely enough to realise that it was talking about VB5 (the first mention of “5” is actually a few lines after the code that I quoted).

It’s not just versions of BASIC that don’t short circuit evaluation of conditions— Pascal does exactly the same, always evaluating both parts of the condition.

Chris: That’s okay. I don’t think of VB.Net when people speak of VisualBasic. (^_^)

I just remembered that there was talk of a mythical BASIC compiler developed by Christian Flöter (of MouseAxess fame) which was said to produce fast code, could be used to program modules in BASIC and being nearly 100% compatible with BBC BASIC including an extremely clever EVAL implementation. ISTR that there were certain stability problems encountered that proved to be hard to fix (e.g. when compiling WebsterXL, certainly one of the more complex BBC BASIC applications). Also ISTR that Christian gave up on it.