arm64

the whole game cries out for complete change

Just so I’ve got this straight, you’re proposing to create a new OS from scratch, that isn’t RISCOS and doesn’t run RISCOS applications?

…and doesn’t appear to know how to code… but don’t worry, the power of wishful thinking can overcome trivialities such as that. There’s no such thing as an obstacle, right?

fishful winking gets you
.
.
.
.
.
nowhere

analyse the module and provide a decompiled listing you can try to modify to make it 32 bit.

Good idea. ☺

Credit where credit is due => Druck.

I’m not sure whether he intended it for use by programmers updating old code, hackers ‘fixing’ abandoned binaries or dabblers but we can all benefit from a nice item of free coding.
!SID in the DDE will do similar but there’s a cost and in some respects it seems less capable.

fishful winking gets you

Up a peak without a cradle?

Leery Viking.

https://www.youtube.com/watch?v=anwy2MPT5RE
?

Know in my longer life and some maturity, that the proof is in the pudding and doing, yet have simply raised a concept that I`ve got caught up in substantiating and defending and rationalising plenty at the expense of getting on track to exploring producing code yet, all of which I am fully aware of with full wits intact.

My interaction with newly acquired Raspberry Pi 1 B+ and Risc OS is awakening my interest in 32-bit even, that I generally suppress, so I am taking my curiosity one baby step at a time, to consider how to ideally port AND create from scratch simultaneously somehow.

To Stuart S: missed a previous post of yours reminding me about this being a Risc OS site. I am in constant full awareness and reasonable, so if I ever mention another OS, it`s for some logical reason and point I don`t labour on about, otherwise I`d sensibly express it somewhere else suitable. Risc OS is my focal interest and priority without question, and progressively moreso today and right now.

this being a Risc OS site.

No. This is a RISC OS site.

Another soul lost!

No. This is a RISC OS site.

Thank you Martin!

Is he a robot? Case insensitive like e-mail, which often loses the dash?

I lost confidence quite a few posting ago!

Dave, is this the time to wield your might?

I lost confidence quite a few posting ago!

I lost the ability to follow what the heck he was on about quite a few postings ago. It comes across as Torchwood style techonogarble interspersed with random quotes from some sort of self improvement book…

Dave, is this the time to wield your might?

Batpoop doesn’t necessarily equal spammer.

That said, I’ve been keeping my eye on an unusual behaviour, that is to say the number of messages that mention the radxa wiki link. If you search for that, you’ll only find two links (at the moment), both of them newer than the one I followed to get the board specs in the first place. That’s…odd.

So my call on whether or not he’s some sort of spammer will depend on whether or not some version of that rock board link turns up again. There is no further need to post it – all of us who are interested have seen it, and Steffen summed it up: just “yet another ARM SBC” with no features in sight to make it a really interesting RISC OS porting target.

So: no more link = batpoop, another link = spammer.
Place your bets now…

5:1 on it’s batpoop. Too much like hard work for a spammer. Unless they’ve written a remarkably witless-teenager-like chatbot, which would be even more work but pretty impressive.

Unless they’ve written a remarkably witless-teenager-like chatbot.

https://en.wikipedia.org/wiki/Tay_(bot)

And my take on it: https://www.heyrick.co.uk/blog/index.php?diary=20160411

Dave, is this the time to wield your might?

I deleted his first posting and his account because it looked like spam to me (I did post “Are we all agreed that this is spam?” and a couple of people agreed), but then he (or the chatbot’s owner) protested to ROOL, so I left his new account and the postings alone.

But either it’s a wind-up, or he’s utterly out of touch with reality.

But either it’s a wind-up, or he’s utterly out of touch with reality.

https://en.wikipedia.org/wiki/Poe%27s_law

And my take on it:

That, as Gavin says, is a cracking good article, Rick. With your permission, I shall link it from my website & my facebook page.

And if our man is a chatbot, it’s a good deal “better” written than Tay – where “better” is along an axis in a different dimension from any of mine.

To Jon A: an intelligent relevant question, that I am answering here right now, if reading further. The current Risc 32 is terrific and will continue to be fostered and enhanced and expanded, no matter what.

To Rick M and Steve P: I cannot quite find the words to express how privileged I am to be on the receiving end of your knowledge and experience you share so objectively and generously to all, even like myself so dev-wet-behind-the-ears.

Am assimilating your deeper-level info about relatively superfluous and therefore inadequate 64-bit ARM CPU instructions, compared to more usable 32- bit.

While continuing to be true to myself and the sincere conviction that Risc OS is worth reinventing, I`ve made a special personal discovery, as a result of being able to look and enjoyably take in Risc OS on my new earlier Raspberry Pi 1 B+ hardware, and am frankly gobsmacked beyond any previous anticipation, with all and the quality it offers. Short and sweet, love it to bits!!!!!!

So, how to do both, meaning improve and then naturally port 32 to 64 inductively on the one hand, while simultaneously create 64-bit deductively on the other, and have an appealing solution to achieve both.

I now access this website, for expressing my productive project perspectives, from and through logging into my Raspberry and Risc OS exclusively only. Furthermore, I now embrace the probability of developing from within this environment as well, in other words, agreeing wholeheartedly about utilizing the current RO as the sure position of strength to innovate from, with a 64-bit version goal in sight, implying porting as the necessary process ahead.

There is another topic I`ve initiated this past week as well, under Forum/General named “RISC4ALL”, that I afresh now realize, provides the second complementary top-down activity approach details, namely utilising a non-ARM platform to create a large 64-bit RISC emulation, for which I have plenty of ideas and resources for implementing, and that I share about entirely, step by step, keeping reference to other hard- and software platforms to a minimum, as long as this site approves.

To Dave H and others: If you folks feel strongly enough about me ceasing on this site, I`ll be completely happy and satisfied exiting both topics and even my membership, and understand my apparent invasion, ha ha, of a long-established UK-based ARM technology culture by my specific different approach and point of view. Can just inform me on email. In fact, will post no more, at least until I hear from you officially somehow, and if nay as I expect, will honor and accept your wishes. Thanks for my time here, and good luck all with your interesting Risc OS activities. Cheers

JF: whatever I’ve said, and whatever anyone else has said, you’re doing no harm. Mildly amusing from my point of view, but I don’t believe for a moment you’re either a bot (I don’t think anyone could write a bot capable of emulating you) or a spammer (you’re putting far too much effort into this, and too few links, to be credibly a spammer). You’re an oddity, for sure, of a different kind from the rest of us (assorted oddities though we already are), but you’re obviously a genuine human, and I for one have no problem with you hanging around here, since your stuff is nicely corralled in only a couple of topics. Cheers!

John:

even like myself so dev-wet-behind-the-ears. […] by my specific different approach and point of view.

That may be the issue right there – one does not just wake up one day and “writes an operating system”. Might I repeat the earlier suggestion of trying to convert a 26 bit module to run on a 32 bit machine now that you have one? That will demonstrate that this stuff is not so easy as you appear to think that it will be.

That is why we likely think your continued suggestions regarding 64 bit are bordering on being spammy – yes, it is something that we may have to look at in the future, but given an entire source written largely in 32 bit ARM it is going to be a long way in the future – as in I’ll probably be dead first (I’m 45). There are many many things that need attention today and 64 bit isn’t one of them.
May I suggest, then, that if you wish to help, you consider:

• One of the open bounties (link at the top of the page)
• Bluetooth stack
• Better internalisation support
• Driver for WiFi enabled “AirPrint” printers
• Anything else you see to be lacking that isn’t 64 bit!

May I suggest, then, that if you wish to help, you consider.

The mistake is to believe that a more modern OS will help us to develop x times faster. And so it’ll be so easy to rewrite all the apps. Perhaps. But keep in mind that RISC OS is probably around 300-500 man-years work. And don’t forget the applications. It’s much more. But the real point is that, even if your project works, it’ll not be RISC OS any more. So not for us.

But the flaw in your idea is not really here. The problem is that the OS will not speed up (so much) development. The API and dev tools will. If you wan’t the perfect API, use Haiku. If you wan’t the best dev tools, use VB, Xojo, etc. I made 14 software this summer with the later. And Windows is not really an example of good design.

Back to RISC OS: perhaps that BBC Basic could be modernized. For example with a port of BBC Basic for SDL, now that it’s open sourced. And it’s C, so it can be compiled later in 64-bit. That’s the way to go: help replacing all components with C code. Help the core devs to add features to RISC OS. And one day, you’ll have a 64-bit version of RISC OS, with a good set of software. And without the need to spend another 300-500 man-years just to have something we already have.

Even the C components of RISC OS and applications will need a through going-over to work when compiled for 64-bit. Been there, done that, many years ago porting device drivers and their support libraries on other 64-bit CPU architectures (Alpha, Sparc, amd64).

Even the C components of RISC OS and applications will need a through going-over to work when compiled for 64-bit.

Certainly. I previously pointed out some architectural differences between ARM32 and ARM64 to highlight that the API is going to change because the registers are very different. For speed, the API may change to follow Linux and put the SWI number into a register beforehand (where the SWI itself is simply SWI 0).

ARM26 to ARM32 was a revision of the same processor behaviour, so most of the existing behaviour worked.
ARM32 to ARM64 is like porting to a different architecture, with the complications that this may involve.

Consider:

if (x == 0)
   x = x + 2;
else
   x = x + 1;

What do you think that would be in ARM32 if we assume x is in R0 and y is in R1?

CMP   R0, #1        ; is R0 1?
ADDEQ R1, R1, #2    ; if so, add two
ADDNE R1, R1, #1    ; otherwise add one

Something like that?

Here’s an ARM64 version (that trashes X2 as a side effect):

CMP   X0, #1          ; compare X0 with '1'
ADD   X2, X1, #1      ; work out the NE clause (result in X2)
ADD   X1, X1, #2      ; work out the EQ clause (result in X1)
CSEL  X1, X1, X2, EQ  ; choose which one to assign into X1

Now imagine how much existing ARM code within RISC OS and its applications use conditionals of this form that ARM describes as “Predicated execution of instructions does not offer sufficient benefit to justify its significant use of opcode space”.

There’s no such thing as an LDM. You can LoaD Pair (LDP) with the pair being either a 32 bit word or a 64 bit doubleword. Everywhere you see an LDM in code, it’s gotta go.

More trauma – you can’t access PC. You simply cannot. So the way to exit a function is to either perform an unconditional branch to an address held in a register, or to execute the RET instruction (which performs an unconditional branch to an address held in a register (X30 by default)).

In other words:

SWI      (OS_File + XOS_Bit)
LDMVSFD  R13!, {R1-R3, PC}  ; drop out if failed

is simple a no-go on ARM64. Now think how much code will be using similar early-exit strategy. Here’s a hint, the macro to do that in the RISC OS code is called “EXIT” and may be followed by a condition code. I make there to be about 155 in the Wimp code alone, and I don’t even want to contemplate what sort of horrible might be required to perform the same sort of behaviour.

To misquote a well known alien: It’s ARM, but not as we know it.

To misquote a well known alien: It’s ARM, but not as we know it.

They may have been a bit strange but not alien¹.
I think the first place that line was used was the song “Star Trekkin” and a quick trawl comes up with the helpful page here

¹ Apparently being from London isn’t alien. :)