general question about riscos.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12
David Feugey (2125) 2687 posts |
Static at compilation time. I do not speak of libraries, but of the keyword LIBRARY.
This could be achieved by the container (elf or other).
My little spreadsheet use EVAL :) Anyway, it can be very useful. Anyway, the idea is to be more close to BBC Basic. |
h0bby1 (2567) 480 posts |
aaaaa |
h0bby1 (2567) 480 posts |
aaaaa |
Colin Ferris (399) 1748 posts |
With Ref to BASIC EVAL – in ABC compiler – could you not use SWI/SYS OS_EvaluateExpression ? |
David Feugey (2125) 2687 posts |
That’s a good idea. |
Vince M Hudd (116) 527 posts |
That’s not a patch on EVAL.
The interpreter part of Trellis does, as well. Every attribute of every object, every location, etc is in a variable. Those variables can be both read and written within an adventure script, thanks to EVAL. However, when I find enough of that incredibly elusive thing I always desire called time I intend to rewrite it from scratch in C, meaning the power of EVAL will be lost to it forever. |
h0bby1 (2567) 480 posts |
aaaaa |
David Feugey (2125) 2687 posts |
Charm is really a viable option, and a very interesting offer. |
Steve Drain (222) 1620 posts |
I might agree, but the arguments against this have been made over decades. It boils down to the adequacy of BBC BASIC for the job, with special mention to the in-line assembler, and the huge investment that has been made in programs written in it. Every other BASIC for RISC OS has struggled to make headway, whatever the intrinsic merit. |
Steve Drain (222) 1620 posts |
But surely you would want the discrimination of a linker, too? BB4W does this to produce a runtime. It crunches the result, but does not compile it. It is worth noting that crunched BASIC programs gain many of the advantages of compiling. Who’s ready to work on StrongBS again? ;-)
I repeat: What do you expect this cut down version to do? Be specific.
Oh yes it is! I do not think you have any idea of the implictions of what you are asking for. It has defeated everyone in the past.
I bet it is. It is very powerful.
I quote once more from the ABC manual: “This would be analogous to including a copy of the interpreter with every program and is therefore not a viable option”. I would add that it also requires a copy of the uncompiled program. |
Steve Drain (222) 1620 posts |
The latter. There is some evil magic, but it is not the main problem.
Not really so simple, but generally true. However, if the compier does not compile certain statements it is not true at all. Take as a simple example this BASIC:
Without checking, I think the second statement assigning 5 to all elements is about a dozen assembler instruction with a simple loop. ABC cannot compile this, so you have to write:
I am sure I do not have to explain why this code, when compiled, will be far larger and much slower to execute than the single BASIC statement. In addition, you cannot generalise that routine into a function that can deal with any array.
Basalt provides a keyword to do this: mystring$ = SWAP$(mystring,0) – SWAP$ can do other, concurrent conversions, too. It is quite a simple routine internally. To do the same with BASIC, most people writing their own code use a lot of string manipulation, which does not compile well. Even using the quickest routine I have been able to devise, it still requires a FOR…NEXT loop and variable assignments. That involves the stack and fetching values repeatedly. Even compiled, it is not going to be as fast as the single keyword, although I am admitting that I have not tested it. ;-(
I have not looked at the code. When I was assessing ABC I would not have known how to. ;-) What I do know, along with Stephan, is that it was not very impressive in a lot of cases, and I suspect that it does some variation on what you write above. There are some circumstances where it really does give a well worthwhile speed increase, but it should not be assumed. |
David Feugey (2125) 2687 posts |
Basic calculation. User enters A%*54*Sin(12) and you get a result. What Eval make with most Basic (BBC Basic’s Eval is much more advanced).
The code in C I submit yesterday is part of an interpreter engine. Opcode based. I made interpreters for years now. It’s fun and easy. The tricky part is the parser. So I think I have a clear idea of what to do, and yes, for simple things, it’s really not a big deal. In C of course :) My current engine is 1/35 the speed of C. It’s ’basic’aly the fastest ANSI C non JIT engine on the scene (and I’m not very good). Main loop is just one instruction. Then I call all the C code with pointers to functions. A branch table in ASM would make the job too. Probably faster, but I don’t code in ASM. I should ask Rick for training :)
And you ask why I wan’t EVAL? :)
Yes, that’s what I suggest.
No reason for this, except if you want to have a ‘full’ Eval. But it’s really not a good idea.
Yes, and also strange mistakes, as some case testing instead of branch tables.
We all agree: there is a lot of room for improvement in ABC. |
Steve Drain (222) 1620 posts |
“A%*54*Sin(12)” The compiler does not keep a record of variable names – perhaps it might – so ‘A%’ is meaningless1. If it did keep names they would have to be stored in some data structure not dissimilar to that of BASIC and interpreted. Interestingly, the Sophie evil magic, the synergistic cache technology, is designed to partially short circuit this interpretation step for variables, by looking up their values directly from the program position. The compiler cannot take advantage of this, so it may be one reason ABC does not always come out much faster. ‘SIN (12)’ is not tokenized, nor does the compiler take note of tokens once compilation is complete. To tokenise this expression requires the tokeniser part of the interpreter, and then the whole expression has to somehow be compiled and executed on the fly. Alternatively, the whole interpreter could be present to evaluate the expression – which rather defeats the intention of compilation. Perhaps you are thinking of a completely separate expression evaluator within the compiler, but would this be BBC BASIC compliant? 1 Not actually true, because ABC keeps the resident integers, so it would know where A% was. It would not be true for any other variable. |
Steve Drain (222) 1620 posts |
I am interested. Could you expand on this, please? |
David Feugey (2125) 2687 posts |
So it should do.
That’s the way we call variables from a C interpreter :)
Why compiled? I speak of an interpreted EVAL. Could be borrow from BBC Basic.
I see your point. But between no EVAL and interpreted EVAL, I saw something better, not a regression. I’m not really a big fun of JIT compilation anyway.
Perhaps just partly. The idea is not to embed a whole interpreter in ABC (that’s not impossible, but not easy… I should test this with some of my opcode to C converters).
Forget it. Stupid confusion with the parser part. Call of opcodes’ code is made with a branch table. The only good way to do this (except in the C world where almost everyone use CASE). I saw even some optimizations, IE sub-opcodes. in my engine (one of), I use a lot this idea. For example a+b is not the same as a+10. The first one is translated by variable+variable and the second by variable+fixed_value. Like this (c=a+b)
And this (a=a+fixed_value)
Nothing complex. I could even make a instr_plus_egal_1 if needed. Of course, you need hundreds of opcodes. Massive slow down if you use CASE. Massive speed up (because of optimizations) with calling functions by name. |
David Feugey (2125) 2687 posts |
I really like interpreters :) For event handling, I insert goto in the code, on fly. Easy… |
GavinWraith (26) 1532 posts |
I remember many aeons ago writing programs in BASIC to plot graphs. One had to input a string expression in x to represent the function to be graphed, and use EVAL; probably the last time I used EVAL in a program. It always struck me as a wretched hack to make up for the fact that BASIC does not let you input functions. You cannot in C either, of course. There are languages which sit somewhere in between being interpreted and being compiled. Even BASIC’s tokenization is a small step to compilation. You want your compiler to do some partial evaluation, on the principle that the less evaluation that takes place at runtime the better. So, for example, if you examine the bytecode produced in RiscLua by it is the same as that produced by However, the compiler is not clever enough to replace by that single assignment. You have to draw the line somewhere.
The nearest equivalent to EVAL in RiscLua is the |
Rick Murray (539) 13402 posts |
Steve:
This is something that perhaps ought to be looked at. Not to work the impossible (so, sorry David, no EVAL) but to see if there is a way to lift some of the various restrictions. 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 was not really aware of the matrix behaviour until you posted something a few years ago. However, I don’t really see any specific reason why not to support what you posted. The syntax is quite clear and unambiguous. Perhaps the author(s) of ABC didn’t know, or didn’t think it was worth the bother for a lesser used function? I don’t know.
That’s fugly no matter how you look at it!
No, the compiler needs to be able to support the meh%()= syntax, that’s the only sensible option.
It’s a lot like VisualBasic. To give an example, VB6 will compile in two different ways. The first is P-code which is like a more tokenised version of tokenised BASIC, and the second is native executable. Both versions require the VB runtime libraries.
I wrote a program to act as a simple bitmap editor of Psion 3a image files. Due to the (dumb!) lack of binary shifting in VB, the method of extracting and rebuilding the bitmap data to/from a big array was basically a lot of multiplication or division by powers of two. It broke my heart to write that, but there you go. The native executable version was maybe four or five times faster at doing this. So, yes. It should stand to reason that compiling something will always beat an interpreter, but this is not always the case. Certainly a compiler should win hands down – compare some code written in BASIC with the same code written in C. However, the actual implementation is important. This may be why VB gives a choice between P-code and native, as they do behave differently. I might fire up the Pi later and try building some dead-easy programs with ABC to see what sort of code is generated. David:
As Steve pointed out, the compiler does not record variable names. This is typical of compilers. Unless you have debugging data, variable names are only an issue between the programmer and the compiler and they have no relevance whatsoever to the final program.
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. The compiler does not keep a record of variable names Why? Part of compiling something is to resolve the references to variables and functions to locations in memory. Look in my MIDI module – you will see function names because this would help a backtrace to present logical information (although it is pointless as I don’t think modules can do that) but the names are not necessary to the program. You could binary-edit all of the function names to be rude words and nothing would be different as far as execution is concerned. Now I’ll ask you this – what is the name of the variable that flags what sort of timing to apply to received MIDI commands? You can’t tell me. You could disassemble the module down to readable code and you still could not tell me. Why? Because the computer works with addresses – locations of things. The names cease being relevant once the compiler has worked its magic. That’s… well… that’s more or less the whole point.
Because that is what is going on. EVAL requires that BASIC interpret the contents of the statement and
Just to be able to support one lesser used command. If you want that, just use BASIC, nothing else is going to come close… To give some examples, I will steal some code from Richard Russell’s post at http://smallshire.org.uk/sufficientlysmall/2007/06/10/writing-a-bbc-basic-compiler-for-the-clr/
Nasty! Have fun working out what is going on here.
This is yucky, but valid. Enjoy parsing that mess.
Fun! Joy! Happiness! What? I’m just disappointed I don’t have a reference to the stuff JGH posted – it was enough to convince me that writing a stupid half-baked BASIC compiler would be a piece of cake. Writing a compiler that would accept actual BASIC would be… let’s say I’d enjoy my worst nightmares more.
Well, um… Seriously? If all this stuff was to be included just to support EVAL, I would really have to ask “is it worth it?”. For you and your spreadsheet, yes, obviously1. For most of the rest of the users of ABC, it might just be a lot of unwanted baggage.
<cough>switch</cough>
This is the power of a compiler. It can spot that a+10 is an assignment and do something like 1 With reference to the other thread on security; 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. |
Rick Murray (539) 13402 posts |
Gavin: I am using bit shift instead of power-of because in C you need to call a function called pow() as the language doesn’t do that itself.
That’s with the ROOL compiler. Want some lulz? Let’s try ABC.
I think I now understand why ABC is slow. One thing that I had planned for my compiler is to suppress all stores that were immediately followed by reloading the exact same data (as I could see this problem from miles away).
|
Rick Murray (539) 13402 posts |
ABC seems to be quite deterministic. Perhaps enough so that a while playing with it might be enough to begin to put together a disassembler.
Gives us (with my annotations):
I’ve saved the compiler from memory (as the file is squished). Errr…. Is ABC written in BASIC and built with ABC itself? Having looked at this, I’m kind of piqued to look and see how the compiler actually works. ;-) |
Chris Johnson (125) 819 posts |
I am pretty sure that Paul Fellows confirmed this was so at one point. |
GavinWraith (26) 1532 posts |
What about ? An interesting game, compiler writing, seeing that there are infinitely many expressions that reduce to a given expression. Of course, most of them programmers are not likely to be daft enough to use in their source code. But obviously some sort of compromise has to be made in adding optimization on optimization.
When Mike Pall’s LuaJIT first came on the scene a lot of people were impressed with its speed. It was then pointed out that JIT compilers have certain theoretical advantages over static compilers, because the beats-as-it-sweeps-as-it-cleans scenario means that it has access to runtime information that a static compiler could never have. Indeed, 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. I believe that a lot of theoretical work has been done on load/store analysis, that would optimize much more complicated cases than what you cite. I am sure the Norcroft compiler uses such analysis. On the occasions when I have looked at disassembly of its output I have been impressed by how rare it is to find obviously redundant code. |
Rick Murray (539) 13402 posts |
For those who may be interested, the layout of an ABC program is: &8000 jumps to a function that sets up the program environment. That’s a brief examination of a couple of ABC compiled programs using Zap. ;-) |
Rick Murray (539) 13402 posts |
I don’t doubt this. I bet there are dissertations that would be impenetrable to most of us. And yes, I think the people responsible for the Norcroft compiler have read them all. Many years ago I looked at some code compiled with TurboC++, OpenWatcom, and Norcroft. I was surprised at how powerful the x86 appears to be given that its code is utterly horrible (and I can forgive TurboC++ some of its peculiarities as it is aimed at a DOS/16bit world). I was also surprised at exactly how clever the Norcroft compiler was. I think one that struck me was a rather messy pile of if()/else if()/etc statements that the compiler rearranged into a jump table (does the compiler see things at function/block level instead of just line by line?). That was clever. Clever enough that I pulled out most of that code and used a switch() construct instead so the other compilers could generate better code ;-) … but yes, the Norcroft compiler is pretty impressive. |
Rick Murray (539) 13402 posts |
The program:
The printf() is necessary or else the compiler would optimise away everything. ;-) So, let’s see what Norcroft did with this. Called with -S option to output a code listing.
Yup. It optimised it down to one instruction. Or, with some annotations:
|
Pages: 1 2 3 4 5 6 7 8 9 10 11 12