CObey

I have translated Obey from assembler to C. The zip is available here, kindly hosted by Rick. It contains the compiled CObey module and its source.

If someone could take a look and give guidance as to getting the code up to standard thanks.

In the spirit of stripping out assembler, I have used a slightly different mechanism to Obey for handling environments. Obey creates a small piece of code to be executed for each Obey file as the exit handler. I have not done this, but it can be put in if people think this is important.

Maybe it will also be useful for anyone looking to add experimental features.

I’m not a good programmer unlike a lot of people here, but I’ll take a look later tonight and see what I think.

So is Obey, the first of many planned ARM>C conversions?

Maybe it will also be useful for anyone looking to add experimental features.

Fantastic that someone is taking an interest in the Obey language. I think the first step would be to get the replacement module doing everything the old one does so nothing complains. Having said that, Obey files are much simpler to update than the large files in other languages.
One area for improvement would be the addition of a case of (multiline) structure, probably a break away from the single line functions available in the past.
“Case of” could handle argument variables, system variables, even the Sys$ReturnCode variable.
I think another thing would be the ability to get reading into variables either from file lines, or from stdin so filters like sed could be used.
A lot of people would like && and || for cmds, but I think that would require return codes for everything then.
Then there is the lack of loops. I have had loops made with alias’s but they only worked up to a hundred or so.
Just finished adding ReadLine32 capabilities to the Debian Ash port for the autobuilder, it took a lot longer than it should have, the manuals reckoned the number returned is one below the cr character, and being invisible, I couldn’t see what was causing havoc until I’d covered a lot of other bases :-(

@ Julie

If someone could take a look and give guidance as to getting the code up to standard thanks.

Had a very quick look at the source and found a little thing you may want to change:

on main/c in read_from_file at the end of the function

  if(error) return error;
}
return error

Unless you’re planning to add some code between the two statements then “if(error) return error;” appears redundant right now, you’ll return error anyway and even if cache is false.

thanks and really nice job! :)

The first problem I would envisage is that the code is compiled with GCC and the roms are compiled using Norcroft. AcornDDE provides skeletons for creating modules in C so that compilation can switch between ram versions and rom versions. This skeleton has macros for all libraries including ${OSLIB}. There is also debuglib available which will output debug text to various destinations if needed. s.veneer won’t compile with ObjASM.

If you have the rom sources and have compiled them then after running !builder set it up to your rom sources and a suitable environment then the libraries in the rom sources are available for you to include in your program as they would be if your program was put into the rom. So you would be writing your program ready to go in the rom. So then when you have sources that would slot into the rom you need to work out how to use git, get a GitLab account with ROOL, fork the ‘obey’ project in GitLab, clone the ‘obey’ project , replace it with your version on a separate branch, push your branch to gitlab and request a merge with the master ‘obey’ project. Detailed instructions are in ‘Documents’ in this site but if you are new to it all your eyes can glaze over fairly quickly. Hopefully I haven’t put you off it is worth persevering and I would have thought a C version of the Obey module would be most welcome.

ROOL were offering free copies of AcornC/C++ to new developers it may be worth getting a copy. I’d practice with AcornC/C++ by compiling a rom – the instructions are in ‘Documents’ on this site.

Alternatively send it to ROOL and hope they are willing to port it to fit in the roms.

If you are struggling to start, If you got Norcroft I could do the makefile for you so you could see how I would do it. Not that that would guarantee it would get accepted unchanged.

As to introducing new features I would get it accepted replicating existing features first. Then think about adding features. It may be decided that adding new features may break something and a separate command for extended features may be a better way to go.

the code is compiled with GCC

Yes, I noticed that. I think the first thing, at this stage, is for a few people to (early on in startup) replace the default Obey with this, and see if things behave “as expected”.
Once it’s had some testing, then it can become a candidate for porting over to DDE (which shouldn’t be hard, it’s small and mostly written in C).

Then it can be tested with a wider range of people (as part of the ROM).

And then…

I would get it accepted replicating existing features first. Then think about adding features.

This. Get current features fully working first. I’m sure somebody somewhere has a real Gonzo Obey file to throw at it.

A feature I’d love to see is some sort of “-noerror” option. In that case, errors will be quietly written to Obey$Error (or whatever) and Obey will continue.
With that, we might finally have a boot sequence that is capable of making it to the desktop even if something is broken. ;-) It’ll only be about three decades late!

But, that’s for another day. For now, testing what’s there does all the same things as Obey.

}
return error

I’d be surprised if GCC didn’t throw a warning for “stuff that looks like coffee outside of a function”.

I meant to write “code”. Autocorrect changed it to “coffee”. Not really my cup of tea, but hang on, I guess that’s as good a reason as any to go put the kettle on… :-)
🍵 <- four billion emoji and no teapot, it’s criminal…

A feature I’d love to see is some sort of “-noerror” option. In that case, errors will be quietly written to Obey$Error (or whatever) and Obey will continue.

On a per command basis, that already exist is the form of X, in the BootCommands module.

}
return error

I’d be surprised if GCC didn’t throw a warning for “stuff that looks like code outside of a function”.

That’s because it is in a function.

Yup Rick, the code is in a function and it’s correct. It’s just a bit redundant the way it is now, however if Julie is planning to add extra logic between the 2 returns then it’s perfectly fine.

I did not comment about GCC because even if it’s compiled with GCC the source does not appear to be using any gnu C dialect, so I pretty sure it’ll compile fine in DDE (obviously Makefile needs some changes for that).

The ROM related statements/info from Colin are obviously correct (and also useful to know, so thanks for sharing!), but by the way I saw the source it doesn’t appear to be finished and ready for that conversion IMHO.

So I assumed Julie wants feedback on the way the Module works and if we found any Obey file that failed working with CObey.

Hope this helps

.

The first problem I would envisage is that the code is compiled with GCC and the roms are compiled using Norcroft

a separate command for extended features may be a better way to go.

If it was just makefiles/build systems you’d think it could be done.

I don’t use gcc so don’t know it’s details. The assembler file in Julie’s code is not like those in the rom sources so unless the asm compiler can compile those files it would take some work. Judging by the changes to makefiles related to GCC I occasionally see in the repository I suspect someone is trying to get gcc to work.

a separate command for extended features may be a better way to go.

I meant it may be better to leave Obey alone for legacy programs (you don’t know if adding more key words will break anything) and introduce an ExObey command/file with more features – if more features are wanted. It would be difficult to write an obey file for your program with the extended features as you would be concerned that some one else may not have a version of the module with extended features so you just end up not using them. BASIC has the same problem.

The assembler file in Julie’s code is not like those in the rom sources so unless the asm compiler can compile those files it would take some work.

It should be possible¹ to use ObjAsm format .s files with AsAsm, however, and that’s part of the GCCSDK. I’ve no idea if it’s included with the native GCC, though.

¹ In the sense that I do, for all of my ASM-based projects. It’s been a while since I’ve assembled on on RISC OS, but they used to work.

It should be possible to use ObjAsm format .s files with AsAsm … I’ve no idea if it’s included with the native GCC, though.

It is.

It should be possible1 to use ObjAsm format .s files with AsAsm,

Does GCC support all the flexibility of the Norcroft macros? I am under the impression that the main issue isn’t so much what the code looks like, but what the macros look like.

If the Arm cpu development as ended as far as RISC OS is concerned, and if the existing assembler version works, it could be a good reason not to introduce a C version, and do it another way.
The attraction of an improved Obey is to not have to run externals so much.
I noticed recently when I built my own !Boot system, that the error reporting is quite good until you run the further (obey) files where the error reports drop off.
Doing more of the boot sequence from the first (!Boot) file would improve things.

Sticking to one line (new) commands I guess Obey would try to run the non keyword as a program, and the remaining line would go as argument(s) when one is found.
It has to return after though, which is slightly tougher.
Do you have a seamless method of doing that?
Edit: Actually just tried running an obey file with a dash command and it returned to that obey file OK. maybe the problem is returning to the calling obey file, I forget now, cant see any issue at the moment.

It erroneously sets Obey$Dir before opening the obey file which means commands like “Obey <Obey$Dir>.^.!Common” don’t work.

four billion emoji and no teapot

About bloody time! https://unicode.org/emoji/charts-13.0/emoji-released.html#1fad6

Doing more of the boot sequence from the first (!Boot) file would improve things.

Sounds suspiciously like a workaround for something architecturally lacking.

Good spot Timothy.

I know someone here mentioned Obey$File before. You might want an Obey$ErrorFile to go with Obey$Error so you know where it came from.

Thanks for all your comments guys :-)

I will have to bite the bullet and cross into DDE land :-/ I wanted to get reassurance that it had a chance of being accepted before I go to all that effort, so the response is encouraging.

I’ve ported the makefile and some of the code to work with the ancient stuff I work with, and… well, it works. I haven’t sorted out the running of tests just yet, but the result is up at:

https://github.com/gerph/cobey

You can find the built version by following the green tick and going to the artifacts off the RISC OS build linked there.

Tiny proof that it works:

https://asciinema.org/a/345529

I’m not convinced that you should have any of the NewApplication stuff in there, because you don’t want Obey to deregister its handlers when another application starts. However, I’ve only skimmed the code, so I could be wrong about what that’s doing.

Also, there’s a lot of faffing with OS file handles. Why not just use C file handles? Whilst you can use C as a meta-assembler, it’s a lot nicer to actually use it the way that it’s meant to be. Plus it means you can re-use that code in unit tests.

Also, there’s a lot of faffing with OS file handles. Why not just use C file handles?

Do C file handles respond correctly to the *Close and *Shut commands?

I’ve always used OS file handles (on all platforms) in commercial products (as opposed to internal tools) as you treat them like any other OS syscall interface, expecting to get sensible errors back to present to the user, rather than unhelpful C errno values

Do C file handles respond correctly to the *Close and *Shut commands?

In what way? They’re just a wrapper around an OS filehandle, with some additional bits required by the C library.

Charles, Obey has to remove its environment temporarily when an application starts because it isn’t an application itself, and the actual application needs to get a chance to remove its handlers.

The example given in the original source is calling an Obey file from BASIC. More explicitly, if you go Supervisor → BASIC → Obey, then running an application, say *Repeat, should cause it to end with an OS_Exit going to Supervisor. Hopefully one day the kernel will be able to do this itself, without the old handler addresses being hidden away inside somebody’s app slot.

Interesting addresses you have there for the workspace block?!

Charles, Obey has to remove its environment temporarily when an application starts because it isn’t an application itself, and the actual application needs to get a chance to remove its handlers.

Yup, that’s right. I’d assumed it was because you were unthreading the obey module as if it were an application, but I see that’s not the case itself.

BASIC has always been a somewhat ugly case, because it expects to only ever be the thing that’s running. Moving to a more process-based system would remove the need for the ugliness that the C libraries use to ensure that they can run sub tasks, and allow BASIC to be freed from its BBC-like heritage.

As for the workspace block, the RMA lives (by default) at &7000000 on the OS I’m running for testing ¹.

¹ Amusingly, it’s found at least 3 bugs in the OS and environment, by just running the CObey module and its tests, so yay for that.

I turned on Fortify, and ran a simple one line test, and it showed up a warning about possible free twice:

https://asciinema.org/a/345702

Line 306 is here:

https://github.com/gerph/cobey/blob/fortify/c/main#L306

if(this) free(this);

I suspect this is because in process_lines you call `close_obey(this, TRUE);` which will `free(this);`, but when you return back to main_command, you then check this and free it if it’s valid. If you really are handing off ownership of this to process_lines, then you should insert a `this = NULL;` immediately before the call to process_lines (and obviously pass the correct this value).