@NutsAboutAmiga

Quote:

However what might be cool if it was possible to run little and big endian programs on the same system, I'm sure there some issues to work out, but that might be more doable. (You might need different SDK to do that.)

On PowerPC it's popular to switch the CPU into LE mode in the kernel then boot a totally LE system. In this case the CPU needs LE support. So far I've not seen any Linux builds for PPC64EL on the X1000 or X5000, if the CPU supports it, I don't know.

But, before that became common, PPC had byte reversing instructions for LE read/writes. I think it's totally possible to run hybrid code that could access standard BE data as wel LE data. Likely easier to isolate code to a module a routine. As long as parameters are passed in registers, whch remain endian agnostic, LE code can go about it's business and work under the shadows of BE code above it.

This would obviously need a custom compiler. For some reason it was decided not to put specific endian support in compilers. Even though it is a real world problem. I've read many an article that says a byte swap macro is good enough for all code and anything else is doing it wrong. Ah no, a macro should not be attached to every single variable access, nor can it be controlled easily down to that level. Given CPUs do have native support for opposite endian access the CPU should be used, over a kludge routine that emulates the operation.

Either variable attributes or a whole code block, endianess would be specified. The compiler would be aware and would use reversing instructions for that access. It's possible it would limit the codes used, but since it only affects read/writes, being limited to a few shouldn't matter too much. This would also help drivers for PCI and USB where the data is in LE order. Another reason for compilers to support specific endianess. In the real world data structures have a specific endian. TCP data in network order is in big endian. I've come across a few discussions on the internet as to whether it should be changed to little endian, to support common endians. But, I think this is a moot point, as x86 can read big endian natively, so why aren't the compilers built to make this transparent for the programmer?

In a similar way, since x86 supports BE R/W in forward order, just as PPC supports LE R/W in reverse order; a possible x86/64 port of OS4 could be made in big endian. By restricting code to use the BE R/W instructons. They might be a tad slower than native endian, but, who cares? At the speed it is running at it would still whip it.

@WolfToTheMoon

can some one please explain me way RISC-V should be soo fantastic ?? and exciting ??...

i think optic or photon/light based or lease cpu's sound intrastring.
i can relly see way RISC-V is such a big deal. its not super fast and what can it do that an very cheap arm cant do ??

@retro

Maybe you should just read the wikipedia article about RISC-V?

https://en.wikipedia.org/wiki/RISC-V#Rationale

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@RISC-V

After a few youtube videos...

We should not worry about ISA change for now.

It's good time to wait & see & meanwhile update OSs that we have today.

***********

A lot of companies seem to be investing in RISC-V.
I think it's because it is more "free" than ARM or Power Architecture.

***********

In past HW companies have been on the mercy of CPU manufacturers and they are now looking possibilities to become "free".
At the same time it has become cheaper to have your own CPU manufactured.

So (unless I'm mistaken) in future smaller niches might/should be able to afford to have their own "CPU" being manufactured, for example around RISC-V.
To me it would indicate we would not need to fight to get documentation for some SoC internals and to try to write drivers again and again. We might be able to get SoC with the internal components that we already have knowledge/drivers for.

HW gurus out there: just say if I've got it all wrong.


********INTERESTING*ARTICLES*******

https://www.theregister.co.uk/2019/07/27/alibaba_risc_v_chip/ (16core, 64-bit, 2.5GHz)
(RISC-V core's are still behind ARM in performance, but I imagine already "fast enough" vs our niche)

https://www.sifive.com/boards/hifive-unleashed (dev board for Freedom U540 chip)

Last edited by KimmoK on 04-Nov-2019 at 07:33 AM.
Last edited by KimmoK on 04-Nov-2019 at 07:22 AM.
Last edited by KimmoK on 04-Nov-2019 at 07:20 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@ssolie

"In order to retrain backwards compatibility some sort of hybrid solution is most likely."

Care must be taken to keep OS simple and technically beautiful.

my thoughts so far....
https://drive.google.com/file/d/1nTBHHXseFZUemO9mcIb3qZ484PJXLhUh/view

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@retro

It's fully open source, cheap and standardized. It should be much easier to get full documentation on RISC-V boards and CPUs than x86 and ARM which should make porting faster.

_________________

@WolfToTheMoon

Quote:

WolfToTheMoon wrote: @retro It's fully open source, cheap and standardized. It should be much easier to get full documentation on RISC-V boards and CPUs than x86 and ARM which should make porting faster.

Yawn! Wake me up when it's done and I'll take notice. Meanwhile updates to Aladdin4D, Bars and Pipes, Octamed etc seems a far more pressing endeavour IMHO!

... or should I be happy that I could use Blender or Tower57 on my new £400 (hypothetical) Tabor machine (also available on my Mac)? Oh yeah sorry the OS itself is the 'Killer App' in Amiga Land!?

Last edited by BigD on 04-Nov-2019 at 11:41 AM.
Last edited by BigD on 04-Nov-2019 at 11:21 AM.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@WolfToTheMoon

Quote:

It should be much easier to get full documentation on RISC-V boards and CPUs than x86 and ARM which should make porting faster.

That is only wishful thinking, unfortunately. The sad truth is, ARM is awfully good documented, x86 documentation is awesome either. What is mostly missing in case of ARM SoC's are the peripherals which you can get either poorly documented, or not documented at all ;) Luckily, there are some exceptions out there.

Do you hope that open source CPU code would force industry to include full documentation and resources for all peripherals placed on the same die? I don't think so.

@michalsc

Well, there are some projects with RISC V that are aiming at a fully open SoC/System design.

_________________

@WolfToTheMoon

Quote:

WolfToTheMoon wrote: @michalsc Well, there are some projects with RISC V that are aiming at a fully open SoC/System design.

Being open doesn't mean that their documentation will be worth of anything. Documenting is the boring part and that shows in quite many opensource projects.

@BigD

Quote:

That's the best marketing for the Tabor I've ever seen.

If you keep up with these silly comments, I'll have to find a way to send you a pint.
I'm still looking for the "like" button.

_________________
question=(2b||!(2b))

@WolfToTheMoon

Quote:

I would wait a year or two as I think there'll be attractive RISC-V targets. I would use that time to make a little endian version of the OS + incorporate much needed improvements like memory protection, 64 bits and the like.

I'd love to see AmigaOS on RISC-V, just putting it out there, but we're probably looking at at least a year just for decent silicon instead of IP cores. Add on the time to build a target system around it and I'd say it might be at least three years before we actually see any good RISC-V platforms to port to.

@bison

Quote:

Something good could be build on top of DragonFly, but by most objective measures Linux would be better. It has more drivers, better software support (e.g. Netflix), and more architectures (ARMv8, POWER and RISC-V). It is also more modular. It could be tricky trying to separate the DragonFly kernel from the rest of the system, whereas with Linux you add components to it rather trying to take them apart. DragonFly has a certain sentimental appeal because of Matthew Dillon's past Amiga history, but that only goes so far.

The reason for choosing Dragonfly BSD over Linux is because Matthew Dillon has already laid a lot of groundwork for Amiga-style communication and structure into it, which would make it a good start. I don't think "[separating the] kernel from the rest of the system" would be any kind of issue. Rather than Linux, even Darwin/XNU would be a better starting point because right there you begin with a real microkernel (Mach) at the bottom even if it's all covered up by the BSD kernel interface NeXT and Apple grew over it.

@Thread

I'm wondering what are the questions ssolie must answer in all this ?

_________________
PowerMac G5 2,7Ghz - 2GB - Radeon 9650 - MorphOS 3.14
AmigaONE X1000, 2GB, Sapphire Radeon HD 7700
FPGA Replay + DB 68060 at 85Mhz

@K-L

Quote:

I'm wondering what are the questions ssolie must answer in all this ?

I'm hoping he wil lfind his way to the unanswered questions in the Amiwest questions thread...

https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=43471&forum=16

_________________
All glory to the Hypnotoad!

@coldacid

RE separating the DFly kernel from userland, and micro kernels: I'm more of a pragmatist that an idealog, so where you see opportunity, I mostly see a lot of additional work.

Matthew Dillon has added a few Amiga-like features to his kernel, but you can't tell by using the system. From the DE (Xfce, in my case) you can't even tell that you're not using Linux.

_________________
"Unix is supposed to fix that." -- Jay Miner

@K-L

Quote:

I'm wondering what are the questions ssolie must answer in all this ?

Yes, as usual, the thread was hijacked by those who know all the answers.

_________________
The Rear Window blog

AmigaOne X5000/020 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition

@Trixie

Quote:

Trixie wrote: @K-L [quote] ................ hijacked by those who know all the answers.

I did no such thing!

_________________
Tinkering with computers.

@AmeegaGuy
Quote:

So now there are two ExecSG kernels. How does this work for end user? You buy Hyperion OS4 then swap in AEON ExecSG or what?

That is incorrect. ExecSG has just changed ownership and is now controlled by a different development team. A-EON has nothing to do with ExecSG either.

_________________
ExecSG Team Lead

@KimmoK
Thanks for the feedback and diagram. I will be bringing your ideas up with the rest of the team.

_________________
ExecSG Team Lead

@K-L
Quote:

I'm wondering what are the questions ssolie must answer in all this ?

Ditto.

_________________
ExecSG Team Lead