C and RISC OS

Those macros. I had no idea what I was looking at. The source is full of them and as I understand it a bit of a barrier to changing toolchain.

RISC OS GCC has AsAsm, which is largely ObjAsm compatible.

If the toolchain was changed there would be a loss of income through DDE. If it isn’t changed there aren’t many people willing to work on the OS code.

Do you really think that the few pounds for the DDE (e.g. as part of NutPi) is a major barrier for people to contribute to the OS? And of those with no money, nobody tried seriously to use GCC and AsAsm (or if they tried, they have kept it secret). Doesn’t look very likely that this is a real problem.

A few days ago I “ported” LibKern.s to GAS. It was just for my own education.

An education in how terrible GAS is, I hope.

There’s no reason to convert the sources to GAS format to use them with GCC. GCC has asasm, which is intended to be a clone of objasm (or compatible with objasm sources, at least).

Those macros. I had no idea what I was looking at. The source is full of them and as I understand it a bit of a barrier to changing toolchain.

Which macros in particular? If I’m to write some beginner’s documentation (because apparently I’m the only one who understands the RISC OS sources), then it would be good to have some examples of confusing macros.

Also, do you have a copy of the DDE, so that you can look up any bits of syntax you don’t understand? If not, you could probably use the armasm docs as reference since the two assemblers have shared history.

If it isn’t changed there aren’t many people willing to work on the OS code.

And if it is changed, will more people will get involved? The pessimist in me says no.

If people really are chomping at the bit in anticipation of building RISC OS using GCC then I would have thought they’d be a bit more pro-active in making the build system GCC-friendly. In the past we’ve had some movement in the right direction (Peter Naulls did a fair amount of work towards making components cross-compilable, and there’s some latent cross-compilation support in there from the Pace days – https://www.riscosopen.org/forum/forums/5/topics/193. There was also a big asasm 2.00 update which made it capable of building all the assembler sources used in 2012-era ROMs). All we need is for someone who’s suitably motivated to pick up from where the others have left off, but so far that hasn’t happened.

Do you really think that the few pounds for the DDE (e.g. as part of NutPi) is a major barrier for people to contribute to the OS? And of those with no money, nobody tried seriously to use GCC and AsAsm (or if they tried, they have kept it secret). Doesn’t look very likely that this is a real problem.

It’s more than a few pounds. It’s my understanding that the NutPi version is crippled to the Raspberry Pi. I can’t speak for others but the other bundled software holds no interest for me either, so there is no value adding in the NutPi package for me personally.
What really interests me is porting to other ARM based platforms.

An education in how terrible GAS is, I hope.

More or less. It’s hard to explain. It was to force me to look at the code and understand it.
It also taught me a few other things.

• Not to use GAS for RISC OS.
• The source is confusing for someone unfamiliar with it.
• Lots of it could be rewritten in C, with some caveats that I don’t know how to deal with.

Which macros in particular?

Not so much the individual macros, but just how they work. They also seem to be kind of splattered around the place.

What is unfortunately needed is someone with time, inclination, the right skillset and knowledge to continue. I don’t know who that is.

I just have to add this. I hate gcc makefiles. While ihave been working with C since the ‘90s maybe I’ve chosen to avoid touching anything that uses a makefile unless it’s simply to build it. I’ll use an IDE with a project file or even another language to avoid them.

I’ll use an IDE with a project file or even another language to avoid them.

Here’s an example of the MakeFile I usually use with my projects:

# Project:   <application name here>

# Toolflags:
CCflags      = -c -depend !Depend -I,C: -apcs 3/32bit -Wcdp -throwback -fahn 
ObjAsmflags  = -APCS 3/32bit -desktop -Depend !Depend -ThrowBack -Stamp -IC:,
Linkflags    = -aif -o $@ 

# Source files used (by object file)
c_files   = o.c_file_1 o.c_file_2
s_files   = o.asm_file_1

# Libraries
libraries = DeskLib:o.DeskLib32 C:o.stubs 

# How to build
@.!RunImage: $(c_files) $(s_files) $(libraries) 
             link $(linkflags) $(c_files) $(s_files) $(libraries)

# A macro for building the C code
.c.o:;       cc $(ccflags) $< -o $@

# A macro for building the assembler code
.s.o:;       objasm $(objasmflags) -from $< -to $@

# Dynamic dependencies:

Put the application name at the top.
Make “c_files” hold a list of (space separated) object files that originate from C sources.
Likewise, “s_files” is the ones written in assembler. Just leave it blank (s_files =) if there are no assembler parts.
“Libraries” is a list of the libraries. I use CLib and DeskLib. ;-)

I’m no expert on MakeFiles. You should use AMU as Make will complain about something or other, all the time.
But it is extremely useful to have a MakeFile, as pressing ShCtrlC in Zap will save the current file and build the project. [there’s probably something similar in StrongEd]

Anyway, when starting a new project I just copy the same basic MakeFile from another project, and change the names to protect the guilty. ;-)

I’m no expert on MakeFiles. You should use AMU as Make will complain about something or other, all the time.

Isn’t AMU a part of DDE?

It pays to have a template. Makefiles are so unpleasant to look at.

I was poking around the OMAP3 source todat and found the GNUmakefiles directory. I have absolutely no idea what they are actually for. All the files state they are a makefile fragments. Were they run by another script of some description, or just nonfunctional WIP bits?

The DDE-based toolchain is what we have, and it works. There is little inclination to expend countless man-hours migrating to another toolchain unless we have to – the few developers that are here have plenty of other things to get on with!

I was poking around the OMAP3 source todat and found the GNUmakefiles directory. I have absolutely no idea what they are actually for. All the files state they are a makefile fragments. Were they run by another script of some description, or just nonfunctional WIP bits?

Makefiles can include other makefiles.

E.g. if you look at the makefile for SoundCtrl you’ll see that it only contains definitions of variables and a single include reference. All the logic for the different build rules is in the CModule makefile and the other makefiles that it includes (StdTools, StdRules, etc). When you’ve got 100+ individual components, using makefile fragments is key to minimising management overheads and ensuring consistent behaviour.

Also note that because we don’t have a proper cross-compilation solution, it’s possible the GNU makefile fragments are completely broken (the DDE makefile fragments are still a bit WIP – I think most components have been changed to use them, but every so often we still find that a few tweaks or changes are desirable in order to keep things straightforward and consistent)

The makefile fragments can be confusing, but you don’t need to fully understand what they do in order to use them. As Rick says, the best approach is generally to copy and paste a makefile from another, similar component/project and then edit it for your needs.

Help me here please. I could have sworn that the NutPi version of DDE was a cut back version used for building for RPi only but I can’t find anything on that anywhere now. Am I imagining it?

I was trying to evaluate which version would be the most useful. At 35 pounds NutPi still has a serious disadvantage. No digital download version. I’d be happy with an SD card image emailed to me / a unique download link. With an SD card there’s the ~month of waiting plus the Russian roulette of Royal Mail & Australia Post combined.

Not going to lie I was considering doing something rather naughty and getting DDE just so I could try an OrangePi port properly, but purchasing DDE is not straightforward. The listings for NutPi and DDE need a little revision too. NutPi is sold as cost + VAT, and DDE is cost inc VAT. It’s inconsistent.

Not restricted in building for the Pi, restricted in building on the Pi.
You can create and build projects for anything, but the DDE will only run on the Pi.
The end of the NutPi page says: Please note: the software supplied with the Nut Pi is specifically built for Raspberry Pi hardware and will not function correctly on any other hardware platform.

but purchasing DDE is not straightforward.

What’s not straightforward? I see a PayPal link beside two options – a digital version or a USB version with temporary zip file to install while awaiting the key to arrive.

Oh, and I believe that under British law, prices shown to domestic (non business) customers are supposed to be VAT inclusive (unless there is no VAT). I clicked the PayPal link for the NutPi and it said the price was £35, so that’s what I’d expect to pay…

In a move I’ll probably be made to regret I bought the DDE, solely for the digital download.
Shame our PM couldn’t have done a public address naked whilst swearing his allegiance to Chthulhu beforehand. AUD$70 is a lot of money.

e: no wait that’s backwards! The same but for the British PM.

If you got your PM involved then he’d probably try to tax you… gotta pay for the fence somehow!

Shame our PM couldn’t have done a public address naked whilst swearing his allegiance to Chthulhu beforehand. AUD$70 is a lot of money.

e: no wait that’s backwards! The same but for the British PM.

1. I’m not sure what the relevance was to anything much
2. I’m not sure I will ever get that image of TM out of my mind no matter how much mind bleach I use

If you got your PM involved then he’d probably try to tax you… gotta pay for the fence somehow!

I wish them luck, whatever dimension that border may be in.

.bq 1.I’m not sure what the relevance was to anything much
2.I’m not sure I will ever get that image of TM out of my mind no matter how much mind bleach I use

1. Exchange rates. If people believe the British PM is somehow more incompetent than the Australian PM, the exchange rates will be in my favour. They always change when people are more sickened than normal by leadership in a country.

2. Ha! I don’t even remember what MT looks like. We’ve had so many PMs in short succession it’s pointless to even care.

Now all I have to do is wait for the drawbridge to open to get the link.

Going back to the OP of this thread. GCC isn’t perfect but it is very capable and can do pretty much anything the DDE can except compile preexisting code written for DDE.

There’s a lot of programs ported from Linux that use GCC. After messing around with it for rogpio I can say it doesn’t seem to have any unexpected caveats.
make on the other hand. I just can’t use it. It just hits me with the error “Too long”, so I just use a simple obey file.

Shame our PM couldn’t have done a public address naked whilst swearing his allegiance to Chthulhu beforehand. […] e: no wait that’s backwards! The same but for the British PM.

I think you’ve got that a little muddled up – TM naked would be an Eldritch Abomination that even Chthulhu would be fearful of.

Do you really think that the few pounds for the DDE (e.g. as part of NutPi) is a major barrier for people to contribute to the OS? And of those with no money, nobody tried seriously to use GCC and AsAsm (or if they tried, they have kept it secret). Doesn’t look very likely that this is a real problem.

In my experience there are three things necessary in a potential developer: time, skills and enthusiasm. A lot of people lack one of those.

Skills are something that can be improved by decent documentation and mentoring (eg a place like this to ask questions) – but require an investment of time to learn new things.

For skilled people, while they might have enthusiasm, time is often in short supply. Enthusiasm is also a fickle thing.

So it depends who you are targeting. Someone who is going to invest a lot of time in a project might not object to paying for the tools for the job. For another person who is not invested, that’s a barrier to entry that dampens their enthusiasm – they might be put off and go hack on a non-RISC OS project instead. There’s never a shortage of those.

Unfortunately, there aren’t many people who are invested enough to jump in and spend lots of time on a RISC OS project. The way to get new people in is to smooth the entry path enough to get them involved, and then their enthusiasm will grow. A big hurdle on step one is not the way to do that.

However, a hurdle-free entry path currently doesn’t exist. Creating one, by using free tools, requires skills that aren’t present in many newbie developers, so they can’t fix the problem by themselves and there are no experienced developers with the time and enthusiasm to do it. Additionally the tools are a funding stream for ROOL so present an additional dilemma: cut off a revenue stream in the hope of attracting new developers, or keep the revenue but also the barrier to entry. (The Castle licence is another barrier to many open source developers)

So it isn’t a great place to be, but there’s no better option I can see at this stage. But it doesn’t mean we shouldn’t admit the problem.

Gold star for eloquence, Theo!
I agree totally, yet I couldn’t quite communicate it effectively.

I’d love to help, but I’m an imperfect specimen. I have enthusiasm. I have very little time. I have a subset of the skills. I’m sure almost everyone has this issue of the missing components as stated so well. I can port X to Y easily, but when it comes to the big picture (Makefiles) out comes the cross and holy water.
Yesterday I made the investment which I’m sure will end up landing me in trouble. I bought DDE. Had a few minutes to try it this morning so I built the OMAP3 kernel as per the tutorial.
Now I’m trying to apply my pathetically short attention span to reading the developer’s guides to create a new target.

I would like to uses GCC to build a RISC OS ROM module, so that I can use modern C++, which the DDE is sadly lacking. I got as far as converting my Linux system call library to work with GCC, and will prehaps have another look at it.