Getting ready to program in C with GCC on RISC OS

I feel I’ve has a similar rant about mouse control, and injecting key codes.

I would rather not do drivers just to do that.
I think I made the source public for RO usynergy on gitlab, user name experimentech.im moving the mouse x and y in C, but no key/button presses.

about mouse control, and injecting key codes.

Did that for my tablet driver. My god, what a palaver…

Don’t use either. Look at the reams of code involved and know that potentially a hundred instructions to call a SWI is utterly taking the….

I’d imagine that 99% of the time the values passed to _IN and _OUT will be constant. It seems like the bulk of the _swi logic could be done at compile time rather than run time, so I question whether it needs to be as inefficient as it currently is.

Of course, with the compiler being closed-source that doesn’t help…

It seems like the bulk of the _swi logic could be done at compile time rather than run time, so I question whether it needs to be as inefficient as it currently is.

Compiler has no way of knowing what other registers any particular SWI trashes on any platform. So regs need saving anyway. I’d stick to using _kernel_swi or roll some _asm if you’re sure.

Compiler has no way of knowing what other registers any particular SWI trashes on any platform. So regs need saving anyway. I’d stick to using _kernel_swi or roll some _asm if you’re sure.

Ahem. I could have sworn that someone mentioned OSLib. Oh, they did.

:-)

Compiler has no way of knowing what other registers any particular SWI trashes on any platform. So regs need saving anyway.

Ah. I didn’t realise that that was the bulk of the work; the code’s all in assembly so it’s a black box to me :)

It may well be opaque to someone that is not familiar with assembly language. That is like C is opaque to some Pascal/BASIC programmers.

That’s a bit of an odd example. Shifting between C and Pascal isn’t difficult. BASIC on the other hand… I see it as more of a super macro assembler. Totally different conceptual family to C etc.
Incidentally I’ve tried and failed more than once to port FreePascal to RO. The docs are just too old and sparse for me.

e: Semi-related. I built GCCSDK on my Pinebook yesterday. I was lazy and did it with gcc 6.3.0.

Thanks everyone. I’m going to go with OSLib, since it seems like the best and most convenient method.

@Patrick
I’m a bit late to the party, but can confirm from my own recent experience that OSLib is indeed the way forward for producing stuff really easily.
I used the following resources:

1. James Hobson’s excellent OSLib YouTube Tutorials
2. Steve Fryatt’s excellent OSLib Written Tutorial

Have fun.

C is nice if well written, C is horrid if not well written.

Most things are horrid if not well written. However some things attempt to resemble English.
Assembler, by its very nature, is not one of those things.

Consider, if you will, a basic structure. Or a string. Even though C fakes strings (a null terminated array of characters), it at least has syntax to make strings resemble strings. Then you get short (16 bit), int/long (32 bit under RISC OS), and long long (64 bit) that will work without the programmer jumping through hoops.
Higher languages have all sorts of virtual data types like currency or date.
Assembler? Well, you have words. And you bytes. And depending on what sort of ARM you’re willing to support, you may have halfwords or doublewords too. There’s no such thing as a string, a string is what you say it is. But you have to work it out, support it, and implement it. You have to keep track of each register that is being used, and what it is being used for. Not as you are coding a function, but everywhere and all the time.
The minutae is extremely important in assembler. And the more time spent dealing with that, the less time you will have to write actual useful software.

Don’t tell me that it’s quicker and easier to write stuff in assembler. Here’s something I threw together that took me, literally, two minutes to write.

#include <stdio.h>

int main(int argc, char *argv)
{
   printf("There %s %d parameter%s\n", ( (argc == 1) ? "is" : "are" ),
          argc, ( (argc == 1) ? "" : "s" ) );

   return 0;
}

I can guarantee that it would take more than two minutes to write an equivalent in assembler.

A higher level language (even BASIC!) packs much more functionality into a single line of code, and it’s a lot easier to debug and extend as you’re looking at recognisable instructions, not a huge pile of cryptic statements.

Still a limit on how far can take the GCC oprimizations before it takes to long to compile.

Get a grip man. I used to build my software on an 8MHz A3000 with the sources on a local floppy disc and the compiler on a FileStore harddisc – and the FileStore E01S was a device built around a 6502 processor and SASI (pre-SCSI) technology harddisc.
“too long to compile”? You don’t know you’ve been born…

There are other open source Pascal Compilers.

Just thought I’d mention, there’s a BCPL compiler (and source) kicking around someplace. I think it used to output programs directly (AIF, not AOF).

You have to keep track of each register that is being used, and what it is being used for. Not as you are coding a function, but everywhere and all the time.

I think the point at which you can do that properly is when you can lie in bed and run through the code segments you are working on as you go to sleep. Otherwise, there’s a lot of comments required in the source.

“too long to compile”? You don’t know you’ve been born…

Normal accent exaggerated "When I were a lad…

Is it worth all that extra optimization when I have to wait for a fairly small program to compile for 2 hours in GCC with -O3 (which is what it takes to beat hand assembly)? Been there done that many times.

Stop trying to compile your stuff on that unexpanded A3000 with 1 MiB RAM with source and object code on floppy disc.

Even CDVDBurn, which is not fairly small by any measure, compiles with GNAT (which is an order of magnitude slower than GCC) in less than 20 minutes (and that’s a full recompile, which is basically never needed). Under Aemulor. So you do something wrong. Very wrong.

With the C compilers of that time it was still faster to compile a 24KB executable than it is to highly optimize and compile a 16KB AIF using GCC with -O3 today.

On the other hand, we have DDE, a faster alternative. And perhaps that a port of TCC could be possible. TCC as a module would be fantastic.

David,

Is your web-site accessible by the public ? If so, then could you post the URL so that I can have a look ?

Apologies if you’ve recently already posted the URL, but I couldn’t find your web site from a quick search.

I’m always interested in RISC OS code, be-it (commented) assembler, BBC BASIC or indeed C. I’m like you – I still mostly use BBC BASIC as that still does all I want (and more!). However, one day (when I retire?) I plan to convert some of my programmes to C, just to increase my understanding (I’ve ‘read’ quite a bit of C over the years but never really written any). Thirty years ago I too was an ARM assembler nut, but these days BBC BASIC on a 1GHz RPi is about as fast as an ARM2 running assembler at 8MHz.

Ralph

https://asmfun.riscos.fr/news.html

No question that you can compile C quickly if you do not care about optimization.

I don’t know what you are referring to. My example was Ada, not C. And it was compiled with full optmization including aggressive inlining.

It would take about 15 minutes or so to compile a project of that size on the RPi 3B+ with GCC -O3, and that is a fairly small project (estimating as source not available)

What exactly takes 15 minutes? What do you refer to if you say “fairly small project”? And how do you know its size, if no source is available??? Your posts and hypothesises get stranger every minute.

As a real-world example, I took TapirMail and compiled it with GCC with RPCEmu with -O3 and it took 95 seconds. The resulting executable is 245 KiB big, source is slightly less than 1 MiB. Not exactly fast, but far from those 15 minutes you estimate for some unknown, but small project.

and it takes the -O3 to beat poorly done hand assembly.

How could you know?

How could you know?

I have compared them, many times.

I think the angle he is going for is “how can you compare the code allegedly compiled in a certain way and allegedly taking a certain length of time when in reality you can’t really measure either given, by your own admission, the source isn’t available”.

That seems a bit fast for nearly a MB of source,

Sounds a bit slow to me, actually.

game that I just compiled (about 110KB for the source), took over 45 seconds with gcc -O3, and VFP profiling,

And how much time is saved using a higher level language than writing in assembly?

We only dissagree on which HLL to use more of the time,

Thankfully under RISC OS there isn’t exactly a lot of choice. ;-)

:) The two at the bottom are the only two I’m really thoroughly familiar with, and even of those my familiarity with Assembler is really pretty rusty – it was very good in 26-bit days (wrote loads of that), and I (literally) wrote the book on v7 (32-bit Assembler), but I’ve never written v7 in any quantity, only little routines to test my understanding when I was writing the book. So I’m confident I could get into it fairly easily, but haven’t seen the need (yet – I can see something coming up…C would be better, but at 69 I’m not sure I want to start getting into that).

I knew Fortran IV pretty well – in the late 1960s…

Nothing wrong with Fortran as a computing language but Fortran 77 is way out of date. Current Fortran compilers are for the 2013 standard. Modern Fortran as a language mixes very well with C. I would be happy to see a RISC OS version of Fortran 95. Perhaps Python 3 would be be an interesting addition as it seems to be widely used on other operating systems.

The programming languages that seem to be easily available … OCAML

Please tell me where from. OCAML is a language with a fascinating pedigree, and I have tried more than once to compile it for RISC OS, without success. If you are interested in virtual machines you should read Pierre Curien’s thesis on the Categorical Abstract Machine (CAM) which is what makes it tick.

Ada

Mostly broken today.

Fortran 77
ICON
OCAML
Objective C

Links?

Perl

OK.

Oberon

Link?

Lua

OK.

Python

(Too) old.

Squeak/SmallTalk

OK.

Forth

Link?

Charm

Broken.

Pascal (gpc)

Link?

C/C++
ARM Assembly
BASIC V/VI

OK.

Ada

Mostly broken today.

As I’m probably the only one still using it…

The state of Ada is quite complicated. The port of GNAT (version 3.03, from around 1995) is based on GCC 2.7.2 (from ancient, distant past).

The compiler itself is 26bit code, but can be made to run (mostly) with Aemulor (ARMv7 only, have had no luck on RPi 3, and on ARMv7, it is more reliable on ARMX6 than on Titanium, no idea why – I need to report this to Adrian, I think there were also problems on Beagle and Panda).

The generated code, with the help of a binary-patched runtime and a few parts from GCC 2.95 (the first version that “officially” produced 32bit clean code), seems to mostly work on anything up to and including RPi 3. The patch for up to ARMv7 can be downloaded from here: https://www.huber-net.de/ada/gnat32.zip – it looks like I have not yet put up the ARMv8 patched runtime anywhere. You also need the modern “link” (never got it to work with GCC’s current linker) and either StubsG or 32bit Stubs, and you can only use the SharedCLibrary runtime, not the UnixLib runtime (since the latter one has not been patched!).

However, there are a few code constructs in Ada that result in illegal 32bit or illegal ARMv7 or illegal ARMv8 code, unfortunately also some of the more useful things in Ada like record representation clauses, so coding is not exactly fun, because you have to do a lot of testing to ensure the compiler hasn’t done something stupid.

At the end of the day, referring to Ada as being “easily available on RISC OS 5” is very very optimistic. Personally, I would recommend “don’t use it unless you have a big pile of legacy code”.

As I’m probably the only one still using it…

I did use Ada too, but not under RISC OS :)

@ David Feugey,

Try googling for ARMForth32 and Fortran Friends ;-).

Regards Ron.

ARMForth32 seems to work on the Pi3. Good :)
Fortran77 needs to be checked.

Lua

Quite nice. I prefer RiscLua6. If I didn’t have a copy I’d swear there was some sort of Mandela effect regarding it.
Currently I’m working on a script that probably shouldn’t be written in Lua to do something magical in the prep stage of building RISC OS.

Python

Recently I downloaded a Python source tree from the official site. On extracting it I had to double check what I’d downloaded because it had a RISC OS directory with instructions on how to build it with DDE.
I also grabbed a bleeding edge copy and got it most of the way through building with GCCSDK. It built most of the objects but choked on something that I didn’t know how to deal with.

Pascal (gpc)

maybe it could be built using the stable release of GCCSDK. I tried adding gpc to the GCCSDK source tree this week. I think gpc was abandoned at gcc4.0.×. After that version it needs to be patched in manually. I couldn’t have been bothered.

I stumbled across the DDE Pascal a while back somewhere. 26 bit I believe. Such a shame it was dropped.

Also TensorFlow and Microsoft ELL won’t build for RO. Although TF was a little more promising. Not exactly languages but I thought I’d mention it.

sdcc chokes on something to do with boost even though libboost is in the autobuilder and builds successfully

Last time I tried, llvm in autobuilder doesn’t build. It grinds away for a very long time before breaking.

Those are my failures which I can readily recall.