BASIC compiler
Steve Drain (222) 1620 posts |
It is fun, and I usually learn something new. However, it does not get us anywhere. |
Rick Murray (539) 13400 posts |
Like most forum posts… the plans for kicking out the mess that is the Territory manager kind of went nowhere. |
Clive Semmens (2335) 3127 posts |
If you learn something new, then it’s got us somewhere. And people like me who have never ridden this particular merry-go-round before are liable to learn quite a lot, so it’s definitely getting us somewhere. Although I doubt you’ll get me starting to use C or C++, although I understand the reasons to well enough. BASIC (+ assembler for heavy grunting) will probably do everything I want to do, quite efficiently enough. I’m very grateful to those of you who make the environment in which that works possible, but I don’t think I’m likely to be much use in that endeavour at this stage of my career! |
Rick Murray (539) 13400 posts |
This is the important part. Define what should be “correct” BASIC (and correct as in logically valid, as opposed to “BASIC runs it”). Consider:
Yup. It’s valid BASIC in that it actually runs. ABC chokes on it – Unclosed PROC/FN body (twice) then Incompatible types for function. Speaking of which…
It is not publicly available as source code. It is part of the DDE, so I would imagine ROOL has a copy of the code. So it is available in the sense that it is still here with us. RiscBasic may or may not have been better, but it appears to have been lost to time.
Which things in particular? If I was going to do something to ABC, it would not be adding structures and better memory handling. Why? Because ABC’s raison d’être is to compile BBC BASIC (as best it can manage). About the only language extensions legitimate to consider are the ones provided by Basalt (as they can be used in a BASIC program, in a fashion). Or, in fewer words, ABC should follow BBC BASIC, not become a hybrid between proper BBC BASIC and who knows what… |
Steve Pampling (1551) 7929 posts |
Bad enough that I wouldn’t have considered it valid, then again my programming1 style always tends to start with a set of empty shell procedures and functions 1 very loose use of the term. |
Clive Semmens (2335) 3127 posts |
Never having used ABC (or any other BASIC compiler) I don’t know the answer to this question: could I expect a BASIC compiler to compile a BASIC program that had embedded assembly language? I suspect there’s no real point though, since with all the real grunt work done by the assembly language bits the speed gain wouldn’t be all that much. (Most of my programs DON’T have any embedded assembly language, but then most of them aren’t doing any real grunt work at all and run in seconds or less on a Pi anyway.) |
Chris Mahoney (1684) 2100 posts |
Considering that you can have embedded assembly in a C file, I’d imagine that it’d be technically possible to accomplish the same in a BASIC file. Whether it’ll work in the real world is another story :) |
Chris Hall (132) 3500 posts |
The RiscBASIC compiler by Silicon Vision was an excellent product and performed an extremely close syntax match with interpreted BASIC. After all developing a programme with the interpreter and then compiling it when it worked correctly seems a sensible development method. It was not 32 bitted, although it was strongarmed. If I was developing a BASIC compiler I would start with RiscBASIC not ABC as that is well known to be much crappier. Not sure who holds the source though. |
Chris Hall (132) 3500 posts |
Never having used ABC (or any other BASIC compiler) I don’t know the answer to this question: could I expect a BASIC compiler to compile a BASIC program that had embedded assembly language? Yes, of course it should handle that. You just need to make sure that certain values are known at compile time. For example:
won’t work |
Steve Drain (222) 1620 posts |
This also needs another/revived topic if discussion is to go further, but I remember that one. As a result I wrote a suite of Configure plug-ins, with support apps and utilities, for creating a user Region 1. This addressed most of the points you made, and more. The problems were that it used Basalt, so was unlikely to get approval from ROOL as an OS extension, and it modified soft-loaded versions of the Territory modules, so relied on knowledge of their data structures. Again, a rather dodgy practice without OS approval. Maybe your recent work on them would be useful there. ;-) For me it was a valuable exercise in understanding Configure and writing macro system variables, but it could not really be released into the wild. 1 The beady-eyed will recognise the influence of Windows here. |
Clive Semmens (2335) 3127 posts |
Yes, of course it should – but do they actually?
Exactly. That was really my question. |
Steve Drain (222) 1620 posts |
Oi! What’s that “in a fashion”? ;-) The point is true, though; you would not be able to compile Basalt extensions. It is also true that a handful of advanced features in Basalt are syntactically a bit contrived: structure elements must be preceded by \ toolbox operations must be preceded by ` long string variables are specified in () |
Steve Drain (222) 1620 posts |
ABC allows the use of the built-in assembler, with just a few caveats. Nevertherless, the manual recommends assembling code separately. I never tried this myself. |
Rick Murray (539) 13400 posts |
Needs a module loaded so isn’t “standard BASIC”, but is around enough to be considered as a viable extension.
Well, you were working within the limits of the existing parser… |
Jeffrey Lee (213) 6046 posts |
If you throw the right keywords into Google, you can find things such as this: A series of blog posts from someone who’s created a BBC BASIC to .NET CLR compiler (“OWL BASIC”) http://smallshire.org.uk/sufficientlysmall/category/computing/software/net/owl-basic/ So really what we need isn’t a BASIC compiler, it’s the CLR JIT/compiler ;-) |
Dave Higton (1515) 3404 posts |
In a way, I hope no-one comes up with a better compiler, for one reason: it will make it less likely for authors to release the source. With interpreted BASIC, you get source. (Brickbats and opprobrium to those who crunch it and don’t also provide uncrunched versions!) |
Steffen Huber (91) 1945 posts |
Whoever writes this compiler just needs to be aware of the problem and include the source in the created executable. Problem solved :-) |
Rick Murray (539) 13400 posts |
Compiled with ABC to a working program. The compiler said: 321 Warning Use of MANUALCODESYNC is recommended to avoid CALL/USR requiring a cache flush on StrongARM. 340 Warning Register R0 unassigned. Defining as constant 0 340 Warning Register R1 unassigned. Defining as constant 1 340 Warning Register R2 unassigned. Defining as constant 2 340 Warning Register R3 unassigned. Defining as constant 3 340 Warning Register R4 unassigned. Defining as constant 4 340 Warning Register R5 unassigned. Defining as constant 5 340 Warning Register R6 unassigned. Defining as constant 6 340 Warning Register PC unassigned. Defining as constant 15 340 Warning Register R14 unassigned. Defining as constant 14 321 Warning Use of MANUALCODESYNC is recommended to avoid CALL/USR requiring a cache flush on StrongARM. 321 Warning Use of MANUALCODESYNC is recommended to avoid CALL/USR requiring a cache flush on StrongARM. But, trust me, you don’t want to see the incomprehensible mess that it outputs. Oh, what the heck. Let’s go for broke…
Yeah. Probably better to make a “Code” file and load that in at runtime. |
Rick Murray (539) 13400 posts |
Off topic here, but Windows did get that bit correct. I understand that the design of Territory made sense in the days when the OS was supplied on ROM and you couldn’t guarantee that the machine had ANY storage (floppy drive could be empty at start, for instance).
Hmmm… The decision of whether or not to release the source has nothing to do with the language it is written in. There’s a lot of open source C, for instance. I would prefer that people have the choice, as it can provide a speed boost to programs that perform lots of calculations. If a program is slow, you can end up with all manner of nasty munging in order to extract more speed, from a simple crunch to the hardcore obfuscation that StrongBS generates (I’m not insulting StrongBS, the results are good, but the result is not a program anybody would choose to work with). What you need to support open source is not to remove choices, it’s to educate people as to why open source may be beneficial.
Well, that’s one way of solving the EVAL problem, I guess. But then why compile in that case? We just need a program to read the BASIC source embedded within and follow those instructions… |
Clive Semmens (2335) 3127 posts |
Indeed. I never want to see the incomprehensible mess that compilers output, whatever their input! But I expect it to work exactly as the program did when it was BASIC with embedded assembly language, only with the BASIC part running faster. But as I think I’ve said before, any serious grunt work is going to be in the assembly language part, so the BASIC stuff won’t take any time to speak of anyway. |
Steffen Huber (91) 1945 posts |
Easy reuse of existing libraries written in other compiled languages. I would imagine something like Interfaces.C in Ada. You “import” C functions which are then callable like any other native procedure/function, and for parameters you have special C-like types that can be converted to/from the native types. |
GavinWraith (26) 1531 posts |
Reuse could mean various things. Compiling different languages to the same object file format (e.g. ELF) and then linking, is one way of reusing code. Another is to have a foreign function interface (ffi) which I think is what Steffen was referring to. In a sense you could say that BBC BASIC’s assembler and CALL function constituted an ffi. LuaJIT has an ffi for C code. |
Dave Higton (1515) 3404 posts |
Not completely true. Interpreted BBC BASIC on RISC OS forces you to provide some kind of source code. It also encourages you to provide readily readable source code, because that’s what you do by default – you have to do extra work to obscure it. (And I wish that no-one did!) |
Clive Semmens (2335) 3127 posts |
I don’t do extra work to obscure my code, but I have to admit to not commenting it as well as I ought…particularly the assembler bits, although they are usually relatively small and easily understood, just doing the billion-times-round-three-nested-loops sort of bits, while all the more involved but less frequently run bits are in BASIC. |
Rick Murray (539) 13400 posts |
While that is technically true, I don’t consider a crunched program to be “source code” in the useful sense of the phrase.
;-) Those who grew up in the eighties may well consider a program to be “readable source code” if it uses single character variables, has multiple statements to a line, has no indenting or whitespace whatsoever, puts everything in UPPER CASE and bonus points if it eschews procedures in preference to a maze of twisty GOSUBs, all alike. Clive raises an interesting point with:
In my experience, I’m a bit of a freak because I mess with assembler. That’s actually part of the reason for my old assembler tutorials, a big “screw you” to the insults. Obviously, being the RISC OS Open forum and RISC OS mostly being a huge wodge of assembler, the ratio of people here that can understand LDMFD is going to be notably higher. However, back then when lots more people used RISC OS and Windows used TrueType fonts with not even the slightest attempt at anti-aliasing, the ratio was a lot lower. People wrote programs in BASIC, but they were jealous of how fast C programs went. Let’s face it, in this day and age there isn’t really a need for a BASIC compiler. That’s why I’d like to tweak ABC but have no designs on writing my own, beyond idly wondering how some constructs would make it from BASIC to code. Our typical “slow” processor clocks around 700MHz (original Beagle or original Pi, take your pick) and the modern memory arrangements put the RiscPC’s treacle-slow memory bus to utter shame. Yes, BASIC will always be slower than C or assembler, however Xeroid demonstrates that with some attention to the algorithms used, it is possible to get a decent playable game from a BASIC program that isn’t even crunched on one of the slower machines (in my case, an original Pi Model B). So for many things, BASIC is plenty fast enough. |