Assembly programming

Over on ‘Ricks’ site some interesting notes on RO ARM Assembly Programming :-)

The most interesting one being DON’T!

Any info to refresh the ‘little grey cells’ might be useful – as the likes of ‘TopModule’ is probably full of Assembly. :-)

The message is clear: don’t programme in assembly language. Use a high level language. These advantages ensue:

1) Each programmer will develop more software, because of the higher productivity of working at a higher level, thereby making more software available for the processors (ARM) and the operating system (RISC OS) that we love;

2) Each piece of software is more maintainable;

3) As the platforms change, new platforms can be accomodated by recompiling.

Please, move your mindset on from the 1970s and 1980s. Programming in assembly language and optimising to the nth degree may have been helpful then, but nowadays they are more like millstones round our necks. Throw them off!

We all agree that we need more and newer software for RISC OS. Let’s just think of one example: Netsurf. That’s already way behind the current state of the art, and is probably falling slowly further behind. Imagine if that had been written in assembly language. If wouldn’t have got nearly as far as it has, and would surely have been abandoned years ago.

It is not sensible to write in assembly language for RISC OS in this day and age. (I’ll allow a possible exception for HALs.)

I’m neither anti-RISCOS nor anti-ARM, and I doubt anyone else on this forum is either.

But writing in assembly language is ludicrous for anyone but a compiler writer (or as Mr Higton says, someone writing HALs).

Why are you anti RISC OS and anti ARM?

No one here is anti-RISC OS or anti-ARM. I am pretty sure of that.

What Druck and Dave gave you are a very useful advices. You do not need to follow them if you do not want to, but please do not try to give different meanings to their words.

@ Colin

IMHO there is only one reason to learn ARM AArch32 assembly language at this point, it’s to help rewriting RISC OS portions in C.

Rick’s blog is an excellent resource, yes. I would also couple it with some publication from (at least) ARM with the ARM ARM, older editions (still available for free on developers.arm.com) have a lot of extra useful information to deepen the knowledge even more. However, for me personally, nothing speeds up learning process more than trying things practically or reading actual source code like, well, RISC OS source code :)

Good luck!

Any info to refresh the ‘little grey cells’ might be useful – as the likes of ‘TopModule’ is probably full of Assembly. :-)

Another interpretation is that Colin might be looking to fix Top Model to run on new hardware. ;) Same sheet, different books. @Colin?

A genuine question: can you write Utilities or Code System Variables without assembler?

Utilities – not at the moment, Steve, if you expect to use the SharedCLibrary. Once we have a uClib which understands that environment then there will be no excuse! Or, at present, roll your own to provide just the library support you need. I think Julie and others have been doing this in the last year or so.

Code variables – you’re likely to be providing them in a module, surely, if they are to be genuinely useful? ISTR one of the cmhg veneers can be abused.

Interesting things, programming languages. So much so that they even spark flame wars and rouse strong emotions. Why would that be, I wonder? Computers are marvellous devices, but without programming languages they would be useless. Back in the 70s it slowly dawned that programming languages were not just for humans to give orders to machines, but also for humans to explain algorithms to other humans. Tools for making ideas precise. To write a program you have to have some mental picture, however imprecise, of what the computer does when it executes the program. Assembly language used to be useful for understanding what the CPU was doing – manipulating data in registers, moving data around, and crucially, explaining threads of execution. As CPUs became more sophisticated and complex the spotlight has moved on to higher-level pictures.

Like CPUs, programming languages have evolved, often as solutions to inadequacies thrown up by previous ones. Those inadequacies often concern the weaknesses of human organization, not just the abilities of lone individuals. There are different sorts of programming language to cater for different sorts of problem. In case you missed it in Archive 25.4, let me puff once again this video on YouTube. If DavidS loves ARM assembly language that is fine – I do too. But most people who program know that it is best to use the right tool for the job. There was a time when assembly language was almost the only tool for using a computer. It is long gone.

Code variables – you’re likely to be providing them in a module, surely …

The ones I have written have been in BASIC and assembler. ;-)

Once we have a uClib which understands that environment then there will be no excuse!

Ouch, I forgot about pushing the latest changes about that one lol

Stuart, if I do, can you please help me there? I have my hands full at the moment.

I can push all I have right now, it should pass all the tests I wrote, but it definitely needs some love on the ASM side. I did changes when I was under a lot of day work last summer, so things were being worked between a coffee and a donut break.

Thanks in advance! :)

Why are you anti RISC OS and anti ARM?

No sorry, I’m just anti-idiot.

I’ve written hundreds of thousands of lines of assembler, starting with the 6502, some 680×0 which might still be on flying around on Airbuses, but most of it on ARM. I loved 26 bit ARM, it was the best I’d come across. But that was the days when you had to use assembler to get the right combination of performance and low resource usage, which could not be done by high level languages at the time on those systems. As soon as compilers were up to the job, I moved to them and used C and C++ because it made my life vastly easier and I was about 100x as productive. I’ve since moved on through C# to Python to be able to get even more done while letting the computer worry about low level things it is best taking care of – that’s real the definition of efficient programming.

I can’t say I didn’t look back, as I used by ARM assembler experience to write ARMalyser (in C (then C++ and C# on other platforms)) to help people port 26 bit ARM to the new 32 bit machines, and ported dozens of applications myself. But I can’t say I ever want to write programs in assembler again, or for that matter even do any serious maintenance on some of my assembler modules, it’s just too tedious, too difficult to follow now, and a waste of the very little time I have.

Plus no matter how good I thought I was at assembler back in the day, I’d be very surprised if anyone reviewing my code couldn’t find a shed load of bugs.

Similar story for me. I was there in the 1970s and 1980s, writing lots of assembly language for Z80, 6802 and 6809, and a bit for ARM2/3. I enjoyed it. But I wouldn’t dream of doing that sort of stuff nowadays. The hardware and tools have moved on enormously.

So must we.

The analogy in hardware is the move in logic design from schematics to hardware description languages. It makes it possible to get so much more done in a given amount of time.

We have to abstract ourselves to higher levels, and let the machines get on with doing what they’re good at.

I loved 26 bit ARM, it was the best I’d come across. But that was the days when you had to use assembler to get the right combination of performance and low resource usage, which could not be done by high level languages at the time on those systems.

This, exactly.

The MAIN negative features of RISC OS are:

• Written mostly in ARM assembler – slow to develop, difficult to port
• Fast and responsive, on very slow processors we aren’t interested in any more
• Small in size, taking no advantage whatsoever of GBs of memory in modern machines
• Includes an assembler as part of the OS, which just encourages people to waste their time

The MAIN negatives of our 32-bit ARM are:

• Low power consumption aimed at embedded systems – which is why the powerful ARM chips we want top run RISC OS on are moving to 64-bit
• Very powerful ISA, with so many new instructions you need to leaving writing efficient code to a compiler
• Deceptively simple, for people who have no clue about superscalar or out of order affects code generation
• Thinking machine language is in any way human readable any more.

As I said I oppose idiocy, and I’m seeing no supply shortage in that department.

So as I say, if you appose [sic] assembly: Why do you appose [sic] ARM and RISC OS?

The answer is that you don’t, so the question is just irrelevant trolling. Maybe write about it on your blog instead?

Had we had a viable compiler option back in the day, I can tell you that far less of RISC OS would have been written in assembler.

@ DavidS

Define “Fast”:

1) Linux network performance are way better than RISC OS on a RPi
2) Linux memcopy, memmove and memset is way faster than RISC OS on a RPi
3) Linux WiFi performance are way better than any WiFi hat for RISC OS on a RPi
4) Linux computational performance are way better than RISC OS on an RPi for parallel and threaded code (multi-core vs single core)

RISC OS only appears more responsive when moving a window around the screen because it has just less levels of abstraction between the user input and the WindowManager redrawing that window. Do you know you can achieve that on Linux too? It’s just that people at KDE/Gnome etc. are not interested in that level of less abstraction, because it would cause issues when maintaining their code and improve features.

Besides, such levels of abstraction can be easily coded in Assembly too, so do not truly represent a difference between using ASM vs using C/C++ etc.

On top of the above, there is also:

5) Linux file system is way more reliable than RISC OS FileCore on an RPi
6) Linux API is way larger than RISC OS API and so people need less coding to complete complex solutions
7) Linux has way more programming languages available on an RPi than RISC OS does

Does that rings a bell? No?

Small in size.

• Linux TinyCore is 16MB Image vs what 4MB ROM? (note the Linux TinyCore image include the InitRAMFS too) Is that truly a relevant difference in 2021 when a RPi comes with up to 8GB of RAM?

Modular.

try to run lsmod on Linux ;)

Includes a decent Assembler as part of the OS.

• Linux has NASM, not a decent assembly?
• Linux also has GAS, still not satisfied?
• Norcrof exists for Linux too, did you know that?
• BBC BASIC for Linux is a touch more powerful than the BBC BASIC for RISC OS

The main positive points of our 32-bit ARM CPUs are:

I am sorry, so you’re saying that by using C, C++, Rust etc.. one doesn’t use an ARM32???? And so, who’s executing our compiled code on RISC OS?

Low power consumption.

What this has to do with coding in C on RISC OS?

Very powerful ISA.

An ISA can be as powerful as you want, but what truly makes the difference is the microarchitecture, that depends on a CPU model, so cannot be generalised.

Coding in Assembly slows your productivity down and, on modern CPUs, for no benefits, except in some very rare cases.

So as I say, if you appose assembly:
Why do you appose ARM and RISC OS?

Here no one is “opposing” anything. Please just drop this, no one hates RISC OS or is anti-RISC OS/ARM.

People here are trying to be helpful and give you some good advice, you are totally entitled to your own opinion, but please do not try to make it sounds like their suggestions are anti-RISC OS because they are not.

[deleted for the sake of decorum, but done with this…]

So as I say, if you appose assembly:
Why do you appose ARM and RISC OS?

Assuming you mean “oppose”…

It has been patiently spelled out to you that no-one here opposes either ARM or RISC OS. As if it were necessary anyway – the very fact that we’re here, in these fora, should be enough indication that we love them.

In the face of all the evidence, if you maintain a belief that anyone here does oppose either or both, then you are at least trolling.

Or worse.

But, knowing what we know today, with the tools that we have today, and with all the different platforms with different instruction sets that we want to support: assembly language is, in almost all cases, indefensible.

Over on ‘Ricks’ site some interesting notes on RO ARM Assembly Programming :-)

I found this series interesting. It’s from a Windows perspective but I suspect that a lot of the fundamentals are the same.

[deleted for the sake of decorum, but done with this…]

It strikes me that this is essentially an argument about the best way to produce a collection of byte code in a particular order that creates an effect, as such, the best way will always be the way that allows a.n.other programmer to read, understand, reproduce or alter the code to produce the same or a slightly different result.

“Assembler” is just a collection of mnemonics that the assembler converts to byte code, C is just a collection of mnemonics that the compiler converts to byte code. The first uses simplistic tags to represent small, simple concepts. The latter uses more extended tags to represent more complex concepts.

The higher level compiled languages win.

Benefits of higher level languages: allows a.n.other programmer to read, understand, reproduce or alter the code to produce the same or a slightly different result – swiftly and, with modern compilers, efficiently.