Poster | Thread |
Hypex
 |  |
Re: AmiWest 2019 clarifications Posted on 4-Nov-2019 3:44:43
| | [ #101 ] |
|
|
 |
Elite Member  |
Joined: 6-May-2007 Posts: 11062
From: Greensborough, Australia | | |
|
| @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. |
|
Status: Offline |
|
|
retro
|  |
Re: AmiWest 2019 clarifications Posted on 4-Nov-2019 5:21:24
| | [ #102 ] |
|
|
 |
Super Member  |
Joined: 16-Dec-2003 Posts: 1049
From: Unknown | | |
|
| @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 ??
|
|
Status: Offline |
|
|
kolla
|  |
Re: AmiWest 2019 clarifications Posted on 4-Nov-2019 5:54:17
| | [ #103 ] |
|
|
 |
Elite Member  |
Joined: 20-Aug-2003 Posts: 2688
From: Trondheim, Norway | | |
|
| |
Status: Offline |
|
|
KimmoK
|  |
Re: AmiWest 2019 clarifications Posted on 4-Nov-2019 6:57:45
| | [ #104 ] |
|
|
 |
Elite Member  |
Joined: 14-Mar-2003 Posts: 5211
From: Ylikiiminki, Finland | | |
|
| @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? |
|
Status: Offline |
|
|
KimmoK
|  |
Re: AmiWest 2019 clarifications Posted on 4-Nov-2019 7:45:17
| | [ #105 ] |
|
|
 |
Elite Member  |
Joined: 14-Mar-2003 Posts: 5211
From: Ylikiiminki, Finland | | |
|
| |
Status: Offline |
|
|
WolfToTheMoon
|  |
Re: AmiWest 2019 clarifications Posted on 4-Nov-2019 8:56:10
| | [ #106 ] |
|
|
 |
Super Member  |
Joined: 2-Sep-2010 Posts: 1342
From: CRO | | |
|
| @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.
_________________
|
|
Status: Offline |
|
|
BigD
|  |
Re: AmiWest 2019 clarifications Posted on 4-Nov-2019 10:56:45
| | [ #107 ] |
|
|
 |
Elite Member  |
Joined: 11-Aug-2005 Posts: 7222
From: UK | | |
|
| @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 |
|
Status: Offline |
|
|
michalsc
|  |
Re: AmiWest 2019 clarifications Posted on 4-Nov-2019 12:27:17
| | [ #108 ] |
|
|
 |
AROS Core Developer  |
Joined: 14-Jun-2005 Posts: 366
From: Germany | | |
|
| @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. |
|
Status: Offline |
|
|
WolfToTheMoon
|  |
Re: AmiWest 2019 clarifications Posted on 4-Nov-2019 13:38:58
| | [ #109 ] |
|
|
 |
Super Member  |
Joined: 2-Sep-2010 Posts: 1342
From: CRO | | |
|
| @michalsc
Well, there are some projects with RISC V that are aiming at a fully open SoC/System design. _________________
|
|
Status: Offline |
|
|
Rose
|  |
Re: AmiWest 2019 clarifications Posted on 4-Nov-2019 14:00:28
| | [ #110 ] |
|
|
 |
Cult Member  |
Joined: 5-Nov-2009 Posts: 982
From: Unknown | | |
|
| @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. |
|
Status: Offline |
|
|
lylehaze
|  |
Re: AmiWest 2019 clarifications Posted on 4-Nov-2019 23:45:34
| | [ #111 ] |
|
|
 |
Super Member  |
Joined: 1-Sep-2004 Posts: 1142
From: North Florida - Big Bend area. | | |
|
| @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)) |
|
Status: Offline |
|
|
coldacid
|  |
Re: AmiWest 2019 clarifications Posted on 5-Nov-2019 19:32:02
| | [ #112 ] |
|
|
 |
Member  |
Joined: 27-Oct-2019 Posts: 39
From: Candinavia | | |
|
| @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. |
|
Status: Offline |
|
|
K-L
|  |
Re: AmiWest 2019 clarifications Posted on 5-Nov-2019 20:06:57
| | [ #113 ] |
|
|
 |
Super Member  |
Joined: 3-Mar-2006 Posts: 1410
From: Oullins, France | | |
|
| @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 |
|
Status: Offline |
|
|
billt
|  |
Re: AmiWest 2019 clarifications Posted on 5-Nov-2019 21:11:06
| | [ #114 ] |
|
|
 |
Elite Member  |
Joined: 24-Oct-2003 Posts: 3205
From: Maryland, USA | | |
|
| |
Status: Offline |
|
|
bison
 |  |
Re: AmiWest 2019 clarifications Posted on 6-Nov-2019 1:11:51
| | [ #115 ] |
|
|
 |
Elite Member  |
Joined: 18-Dec-2007 Posts: 2112
From: N-Space | | |
|
| @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 |
|
Status: Offline |
|
|
Trixie
|  |
Re: AmiWest 2019 clarifications Posted on 6-Nov-2019 7:00:20
| | [ #116 ] |
|
|
 |
Amiga Developer Team  |
Joined: 1-Sep-2003 Posts: 2084
From: Czech Republic | | |
|
| @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 |
|
Status: Offline |
|
|
Signal
|  |
Re: AmiWest 2019 clarifications Posted on 6-Nov-2019 14:16:02
| | [ #117 ] |
|
|
 |
Cult Member  |
Joined: 1-Jun-2013 Posts: 664
From: USA | | |
|
| @Trixie
Quote:
Trixie wrote: @K-L
[quote] ................ hijacked by those who know all the answers.
|
I did no such thing! _________________ Tinkering with computers. |
|
Status: Offline |
|
|
ssolie
|  |
Re: AmiWest 2019 clarifications Posted on 10-Nov-2019 3:16:49
| | [ #118 ] |
|
|
 |
Elite Member  |
Joined: 10-Mar-2003 Posts: 2755
From: Alberta, Canada | | |
|
| @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 |
|
Status: Offline |
|
|
ssolie
|  |
Re: AmiWest 2019 clarifications Posted on 10-Nov-2019 3:21:32
| | [ #119 ] |
|
|
 |
Elite Member  |
Joined: 10-Mar-2003 Posts: 2755
From: Alberta, Canada | | |
|
| @KimmoK Thanks for the feedback and diagram. I will be bringing your ideas up with the rest of the team.
_________________ ExecSG Team Lead |
|
Status: Offline |
|
|
ssolie
|  |
Re: AmiWest 2019 clarifications Posted on 10-Nov-2019 3:24:53
| | [ #120 ] |
|
|
 |
Elite Member  |
Joined: 10-Mar-2003 Posts: 2755
From: Alberta, Canada | | |
|
| @K-L Quote:
I'm wondering what are the questions ssolie must answer in all this ? |
Ditto.  _________________ ExecSG Team Lead |
|
Status: Offline |
|
|