Programming Instruction

Gerf on IconBar is giving informed instructions on splitting a program up into smaller lumps – to help in the testing of the code.

Link, for those of us who are far too lazy to go looking?

https://www.iconbar.com/

Link to the article itself

http://www.iconbar.com/articles/Testing_on_RISC_OS/index1688.html

I just got round to skimming the article and to quote one part, with its footnote:

Name the file something clear about its function. Names are important to focus the intent. Naming the file Wimp13, or vduk is not an option.¹⁴

¹⁴ Facepalm.

Yes. I don’t think I could have put it better.

PS. Can anyone explain why the source for the HAL is almost exclusively in assembler?
Legacy modules no one got round to converting to C I can understand, but stuff that was written this century?

I don’t think I could have put it better.

A lot of RISC OS is like that. The Wimp and VDU are particularly bad, but the kernel has bits well named and, well, what’s Arthur2 and Middle?

Can anyone explain why the source for the HAL is almost exclusively in assembler?

Easy. RISC OS is not a particularly C friendly system because the C library is an addition that came along later. It has specific environmental requirements that much have been just “too much trouble” at the level of the HAL. Some things can be written in C, but these things need a lot of care and many restrictions on what can be done. It’s basically using the compiler to make “readable algorithms”.

So this low level stuff is in assembler.

It has specific environmental requirements that much have been just “too much trouble” at the level of the HAL. Some things can be written in C, but these things need a lot of care and many restrictions on what can be done. It’s basically using the compiler to make “readable algorithms”.

So this low level stuff is in assembler.

The use of bits of CLib is where you could perhaps have a small file with the required library elements as a bit of assembler.
You could make its purpose obvious by calling it something like “CLibAsm” and then put it in a sub-directory of the specific hardware platform HAL called “s”

Then again, making part of the more generic aspect of the HAL might be a better idea.

In Select 4, the page manipulation algorithms which were used to construct the initial page tables used by the system, before the MMU was turned on, were all written in C. There exists a small C implementation of printf in there which I probably knocked up in a few hours, but that’s it for C library-like functions.

It’s really not complicated stuff to do, and you don’t need to do it if you’re just writing simple C code to implement (as Rick says) readable algorithms. Strictly, so long as you have some writeable memory for a stack, you can use C code for writing anything you like.

For examples of how to do have C code that’s integrated into other languages, I’ve written and spoken about it once or twice…

I gave examples of the implementations of C code in assembler modules in the presentation to ROUGOL, and most recently gave an example of doing so in a discussion of how to begin the process of making modules in higher level languages, for modules that are largely assembler. Find this description here: https://www.riscosopen.org/forum/forums/5/topics/15990#posts-112599 which uses one of the examples that I used in the ROUGOL presentation.

I believe it’s also mentioned in the Rambles a few times in the course of explaining the manner in which new functions were added in a more maintainable way.

And those who were around on Usenet’s comp.sys.acorn.programmer group in 2003 may remember my ‘Super Quick Guide To Creating Code To Use From Other Languages In C’. If you don’t, google groups will help you – it’s here: https://groups.google.com/g/comp.sys.acorn.programmer/c/DwyM1z5_Sss/m/FsLdoqJahOAJ and the full text, responses and example code are captured here: https://usenet.gerph.org/CGuide/

I guess my point is that I’m still a broken record repeating the same things. It’s just that in the case of the Iconbar article it’s to reinforce that writing things in a higher level language will make it possible to test (and still has the side effect of making things more modular, more amenable to running in new environments, and more accessible to others).

you don’t need to do it if you’re just writing simple C code to implement (as Rick says) readable algorithms.

That was the concept I was aiming to put across. Unless you use library items you can operate producing C source that compiles into something usable.

I guess my point is that I’m still a broken record repeating the same things and waiting for people to listen.

Fixed that for you.

Sooner or later, just maybe…

Can anyone explain why the source for the HAL is almost exclusively in assembler?
Legacy modules no one got round to converting to C I can understand, but stuff that was written this century?

The push for C in the kernel is fairly recent, most of the HAL was written long before anyone seriously thought about migrating away from ARM.

I believe it was mostly written “behind closed doors”, with no community review during the process. Until the Pi4, that seemed to be the norm.

The bulk of the codebase is nearly 40 years old and still follows Acorns “legacy” structure and naming convention. Idiotic filenames, monolithic code, heavy use of two letter assembler labels, poor documentation, lack of inline comments etc. and for “reasons”, some OS devs have decided to perpetuate those bad practices with many of the OS changes and additions.

We can’t really have a dig at the devs though, they’re doing this in their spare time, for free and probably aren’t professional programmers in their day jobs, or had formal education on how to develop in a modern way. At this point your relying on common sense and peer review to keep to a “standard”.

Although peer review is getting better, I’m not sure if code submissions are being rejected because they’re not formally documented on the Wiki, or because the code isn’t commented, or they’re not written to a “standard”. If I’m honest, with such a small base of people submitting code, I’m not sure we have the luxury of being that pedantic.

I think it can be inferred from Charles’s post but UIUI One of the problems is you can’t use the Shared C library as it won’t have been loaded yet. How much more difficult it makes things I’m not the person to ask.

bq I think it can be inferred from Charles’s post but UIUI One of the problems is you can’t use the Shared C library as it won’t have been loaded yet. How much more difficult it makes things I’m not the person to ask.

I suppose it depends on the code you’ve got to implement, but as above:

In Select 4, the page manipulation algorithms which were used to construct the initial page tables used by the system, before the MMU was turned on, were all written in C. There exists a small C implementation of printf in there which I probably knocked up in a few hours, but that’s it for C library-like functions.

Or, if you dibble in the Pi HAL source and read the content of the assembler file “CLib” you find a routine for “memcpy”

So the answer to the question “how much CLib functionality do you need?” appears to be “not a lot”

PS. Can anyone explain why the source for the HAL is almost exclusively in assembler?
Legacy modules no one got round to converting to C I can understand, but stuff that was written this century?

A few reasons I can think of:

1. The IOMD HAL was born from the IOMD-related bits of the kernel/OS sources. These would almost certainly be assembler (I’m not aware of any C hardware drivers in RO 3.7). Why rewrite that code in C, when it’s quicker & safer to just leave it in assembler?
2. There are some technical hurdles with using C in the HAL/kernel that were probably easier to ignore than to tackle head on. So although some of the early post-IOMD HALs used C for some components (e.g. PCI code in the Tungsten HAL), the main bulk remained in assembler.
3. The HAL does a lot of low-level stuff (pre-MMU code, poking hardware registers, coprocessor interactions, etc.) which C/Norcroft isn’t always well-suited to
4. After the OS went open-source, a lot of the new HALs have been created by people who were at the time new to the RISC OS sources (myself, Willi Theiss, Adrian Lees, Michael Grunditz, etc.). With no examples of a fully C HAL available to work from, why would a newcomer add risk to their efforts by trying to develop a fully C HAL? And if they stick with assembler, it’ll be much easier to copy & paste large chunks of the existing HALs to give themselves a headstart in writing their new one.

We can’t really have a dig at the devs though, they’re doing this in their spare time, for free and probably aren’t professional programmers in their day jobs, or had formal education on how to develop in a modern way. At this point your relying on common sense and peer review to keep to a “standard”.

FWIW I am a professional programmer in my day job. I do have a degree in computer science, but I wouldn’t say that qualifies as a formal education in “how to develop in a modern way”, since it was a fairly broad syllabus which covered a lot more than just programming. I’d imagine that if I’d taken a degree that focused more on software development then I would have finished it with a different outlook on things like coding standards, testing, choice of language, etc., which would have benefited the OS if I’d applied those insights to it. But if I’d gone down that path, maybe I’d have taken one look at the OS sources and gone “Oh, hell no!” and never attempted to do anything with them? So I think there’s definitely a challenge of finding people who are comfortable with/capable of working on the sources in their current state, but are progressive enough to prioritise improving the quality of the sources, and who have the time and determination to be able to produce meaningful results (which may also involve trying to solve the problem of “why haven’t my merge requests been accepted yet?”).

So the answer to the question “how much CLib functionality do you need?” appears to be “not a lot”

Correct. Lack of CLib isn’t a major issue.

I think Adrian L did a cut down Lib of the SharedCLib – I’m not sure that he has released it yet.

Having copied Gerf’s ‘story’ across to VRPC DL- what a fuss – into Textease – using its ability to read aloud and scroll down the text as required when it gets to the bottom of a page.

Talk about testing :-) I’m trying to 32 bit !Playback.

Stiffing VRPC DL ro4.02 and the latest 5.xx.

Puzzle ?

Does this make sense.

Mrs r9,cpsr
Orr r8,r9,#3
Msr cpsr_c,r8
Nop
Do something

Msr cpsr_c,r9 also tried (all cxsf

Was
mov r9,pc
Orr r8,r9
Teqp r8,#0
Nop

Do something

Teqp r9,#0
Nop

[Edit]
Changed cpsr_x to cpsr_c

@Colin: I’m guessing you’re trying to enter SVC mode from IRQ mode? This trivially derived from the ARM ARM:

For example, a good way to switch the ARM to Supervisor mode from another privileged mode is:
MRS R9,CPSR ; Read CPSR
BIC R8,R9,#0x1F ; Modify by removing current mode
ORR R8,R8,#0x13 ; and substituting Supervisor mode
MSR CPSR_c,R8 ; Write the result back to CPSR

stuff

MSR CPSR_c,R9 ; Write the original back to CPSR

Hmm… 0×1F → 0xF and 0×13 → 0×3?

Memory fault – memory fault – it should be ‘C’ not ‘X’ repeat!! Go to beginning of the line. :-(

Prog now running.

It may make sense if what you wanted to do was produce a set of instructions that would confuse someone. However, you’ve not actually stated what you were wanting to happen, so it’s left to the reader to guess. The ‘was’ example is incomplete, so you can’t even say that the two are compatible.

I’m going to guess that you were trying to enter SVC mode from IRQ mode (eg a ticker event), because that’s the most likely use of a sequence similar to this.

    MRS r9, cpsr                ; copy all the CPSR flags to r9
    ORR r8, r9, #3              ; set bits 0 and 1 of the flags:
                                ;    USR <invalid>
                                ;    FIQ -> IRQ
                                ;    SVC -> SVC
                                ;    MON -> ABT
                                ;    ABT -> ABT
                                ;    HYP -> SYS
                                ;    UND -> SYS
                                ;    others -> undefined, ABT, or SYS
    MSR cpsr_x, r8              ; use this new value to set the extended flags

So… no, it doesn’t make sense.

You probably meant the last instruction to be:

    MSR cpsr_c, r8              ; use this new value to set the processor mode

!Playback written in 1992 seems a good idea – it records mouse movements and clicks.

With monitors with much larger screens it seems more usable now.

Either showing how a Prog works ie something like Paint or ArtWorks or Draw or for repeat testing of a Prog.

At the moment BASIC/Module PlayBack is having a problem when saving a file – instead of letting you save a file by dragging a save box – it jumps to error window about dragging the file save box.
So more fun! :-)

Mouse recording assumes an application’s window opens in the same place every time – they don’t!

I see your point – it’s a pity the author didn’t allow star commands to be added to the file.

Ie access to WinOpen commands etc.

Seems there had been a change in saving a ‘save window’ – since 1992.

Trying to follow the code of ‘PlayBack’ – I see Gerf’s point about splitting up the code into usable chunks.

The code has usable names and tidally written but around Wimp poll – where does it go.

The code has usable names and tidally written but around Wimp poll – where does it go

For a while I was thinking you meant the twists and turns in the Wimp source, but then I realised you mentioned usable names.