Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
|
|
|
|
Poster | Thread | ne_one
| |
Re: Why was AmigaOS 4.X developed only for PowerPC? Posted on 3-Sep-2018 22:20:55
| | [ #581 ] |
| |
|
Cult Member |
Joined: 13-Jun-2005 Posts: 905
From: Unknown | | |
|
| @number6
My point is that many of us lobbied Hyperion to reconsider their strategy 15 years ago and they remained unrelenting despite what was going on in the industry.
Hindsight is always 20/20 but they didn't have a lack of information, they chose to ignore it. |
| Status: Offline |
| | Karlos
| |
Re: Why was AmigaOS 4.X developed only for PowerPC? Posted on 3-Sep-2018 22:30:00
| | [ #582 ] |
| |
|
Elite Member |
Joined: 24-Aug-2003 Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition! | | |
|
| @ne_one
There is no "benchmark of success" for the Amiga because, quite frankly, it wasn't a success. It set the standard for what computers would become in terms of multitasking, multimedia and user interfaces but it never achieved it's potential. _________________ Doing stupid things for fun... |
| Status: Offline |
| | number6
| |
Re: Why was AmigaOS 4.X developed only for PowerPC? Posted on 3-Sep-2018 22:45:42
| | [ #583 ] |
| |
|
Elite Member |
Joined: 25-Mar-2005 Posts: 11540
From: In the village | | |
|
| @ne_one
Quote:
My point is that many of us lobbied Hyperion to reconsider their strategy |
I'm not sure who you lobbied here.
The managing partner (there were 2) who admitted his interests lay elsewhere: Quote:
Source
or this one: Quote:
Benjamin Hermans stepped down in 2003 |
Source
Perhaps you meant the Friedens? who became the presence on this website in particular over the years? If so, you're talking about contractors, not Hyperion.
#6_________________ This posting, in its entirety, represents solely the perspective of the author. *Secrecy has served us so well* |
| Status: Offline |
| | cdimauro
| |
Re: Why was AmigaOS 4.X developed only for PowerPC? Posted on 17-Sep-2018 20:06:18
| | [ #584 ] |
| |
|
Elite Member |
Joined: 29-Oct-2012 Posts: 3621
From: Germany | | |
|
| And finally some time to answer something here...
@matthey Quote:
matthey wrote: Quote:
cdimauro wrote: OK, and I understand the idea, but the problem with the existing Amiga applications remains: they don't know what MEMF_SHARED is. Only OS4 applications are aware (and maybe mostly they use) of it.
So, the question is very simple: what to do with the existing 68K applications? Do they run on the NG Amiga o.s. in a sandboxed/emulated environment? OS4 applications can be more easily ported from this PoV, but they are also more different from the o.s. 3.x ones (e.g.: library interfaces and/or shared objects). New, NG Amiga applications of course have no problem, but the main question here is about the legacy ones, and eventually how to port them (if it's possible). |
I wouldn't assume that AmigaOS 4 applications have the memory flags set properly. Supposedly there is virtual memory but I don't know if pages swap enough for adequate testing. |
And you're talking about OS4 applications, which should know about such new MEMF_SHARED flag: imagine the mess with the existing 68K ones, which ignore it completely. Quote:
Quote:
I may sound too rude, but I don't give a s**t to badly written applications which depends to such kind of low-level and platform-related information.
My target is always good applications, which didn't used 4 as a stupid shortcut to sizeof(APTR). If coders were so lame to use 4, then their applications don't and shouldn't deserve any attention. |
Pointers are stored to memory where they have a size. It is difficult for some types of programs not to make assumptions about the size of pointers. |
That's why sizeof() built-in function et similar exists and should be used. Quote:
The AmigaOS also makes some assumptions as can be seen by APTR's in structures. |
APTRs used in structures aren't a problem, because the APTR type/definition can be redefined by a 64-bit platform. Quote:
Quote:
True, but the reality is that C/C++ (and Pascal/Delphi/FreePascal, etc.) coders usually use malloc because it's THE standard way to allocate memory with such languages.
I bet that many coders did it, and here you can do nothing, unless you have the sources and maybe a lot of time to patch them to better use memory allocation on the Amiga o.s.. |
Now you are concerned about "badly written applications". It isn't that difficult to patch badly written OS friendly programs with the 68k.
How many programs have been patched for WHDLoad? What percentage of Amiga games have been patched? How much easier is patching OS friendly programs than copy protected games? |
Sure, but it depends on the size of an application, and Amiga ones aren't that big stuff.
Porting complex ones like OpenOffice or similar is a challenge. Quote:
Quote:
It is obvious that the SIMD unit and new (security) extensions were used for the "64 bit A64" which weren't for the "32 bit A32". I have seen some large improvements from moving to AArch64 where auto-vectorization is used. Otherwise, the performance has been disappointing, |
Then you can remove all FP applications, but the trend doesn't change. How do you explain BZip2 Decompress results, for example? At the same time the huge drop on Dijkstra can be explained by the intensive pointers usage. Quote:
especially on entry level 64 bit hardware like the Cortex-A53 (Raspberry Pi CPU). Look at the single core 7-Zip benchmarks for example.
mode | compression | decompression 32 bit ARM32 880 1600 32 bit Thumb2 890 1370 64 bit AArch64 860 1420
Best compression performance: Thumb2 Best decompression performance: ARM32
https://7-cpu.com/
The Thumb2 and ARM32 performance should be better with a 32 bit CPU too. |
But you're talking about a low-end AArch64 implementations now. The ISA is the same, but micro-architectures can be completely different, and Apple processors clearly shows it. In fact, from your link there are results for its A9:
mode | compression | decompression 32 bit arm32 2100 1960 32 bit arm32-thumb2 1940 1900 64 bit arm64-lsl 2500 2510
Best compression performance: arm64-lsl Best decompression performance: arm64-lsl
Same processor, but 64-bit mode greatly beats the 32-bit one. How do you explain it? Quote:
Quote:
They aren't dirty. Some modern 64-bit ISAs allow to use some higher bits of the 64-bit pointers for applications use; those bits are automatically masked-out when accessing the physical memory.
So, not only it's not dirty, but it's very convenient to make use of this possibility to accelerate some operations. |
Tagged pointers are dirty pointers. The hardware can't provide the tagging when the address bits are being used for addressing. The address space used by the tags is gone for software using tagging. |
Sure, but if the ISA allows to use some bits for tags you cannot talk anymore of tagged pointers. That's what happens with ARM64, where tagged pointers are part of the ISA.
Of coruse, if you use such bits for tags, then the virtual address space is reduced, but 64-bit pointers still offer plenty of addressable memory. Quote:
Quote:
Is it really that useful? Actually TLB caches do a very good job, and the virtual-to-physical memory translation takes very little time (and it's hided by longer pipelines and/or out-of-order execution). |
It depends on the setup for the caches and TLB, but the costs can't be completely hidden and can be substantial. Performance and energy efficiency costs include the need to flush caches on context switches, TLB thrashing with large programs and heavy multitasking/multi-core use, cache coherency issues with multiple cores and L1 caches, etc. Performance can drop by 50% in some cases and the TLB alone can consume more than 10% of the CPU power. Responsiveness and consistency can be greatly affected by TLB hardware, especially on less than high performance CPUs. Did you see my post comparing the most responsive RTOS vs Windows XP on a PII@400MHz (low clock is typical of most embedded systems)?
OS | Response time | Latency | Latency Jitter Windows XP 200 848 700 uC/OS-II 1.92 3.2 2.32
Windows XP takes 104 times as long to respond, has 265 times the latency and has 301 times as much latency jitter as a RTOS without using the MMU on the same hardware.
https://www.lisha.ufsc.br/wso/wso2009/papers/st04_03.pdf |
OK, but you're talking of completely different o.ses and needs. A RT o.s. is totaly different from a desktop/server, so there's no surprise about the data that you reported.
Do you want a RT o.s. as the foundation for a desktop platform? Quote:
Quote:
I was talking about Windows, not Linux. On Windows many applications have >4GB entry point and code ("text").
For example: diSlib, http://ragestorm.net/distorm/ 64 bits PE found Image Base: 0x140000000, Code Size: 0x2209000 Entry Point RVA: 00008b40 Sections: 1.Name: .text , VA: 1000, Size: 2209000, Flags: 60000020, Start: 140001000, End: 142209fff 2.Name: .rdata , VA: 220a000, Size: 69c000, Flags: 40000040, Start: 14220a000, End: 1428a5fff 3.Name: .data , VA: 28a6000, Size: 1ce000, Flags: c0000040, Start: 1428a6000, End: 142a73fff 4.Name: .pdata , VA: 2a8d000, Size: 14b000, Flags: 40000040, Start: 142a8d000, End: 142bd7fff 5.Name: .didat , VA: 2bd8000, Size: c000, Flags: c0000040, Start: 142bd8000, End: 142be3fff 6.Name: .c2r , VA: 2be4000, Size: 1000, Flags: c0000000, Start: 142be4000, End: 142be4fff 7.Name: .rsrc , VA: 2be5000, Size: 539000, Flags: 40000040, Start: 142be5000, End: 14311dfff 8.Name: .reloc , VA: 311e000, Size: 41000, Flags: 42000040, Start: 14311e000, End: 14315efff
This is Excel 64 bit. |
It looks like you are correct about using 64 bit addresses. I expect Excel is not using the small code model. Can you show relocation tables too? If it is using relocation table relocation types of R_X86_64_64 then it is using inefficient absolute addressing where R_X86_64_PC32 type relocations are efficient RIP relative relocations. |
The dislib application doesn't show any relocation: Imports: Exports: Relocations:
Which makes sense, since I see a lot of RIP memory accesses, and very rare absolute addressing (almost completely used for accessing the Thread Local Storage). Quote:
Quote:
Then it means that this is the second case I was listed. So, o.ses aren't guilty. It's the government which created such over infrastructure to intercept/gather/save/analyze massive amount of private data coming from U.S. citizens and foreigners. |
The developer of the OS which allows backdoors is complicit. They are aiding and abetting the government in their probably illegal unconstitutional activity. It should be good for business to resist governments and protect customer privacy. |
Is there any proof regarding the presence of backdoors on o.ses? Quote:
Quote:
Graphic cards usually have a 128/256/512MB Aperture Size in the regular address space, where graphic memory is mapped from time to time, depending on the needs.
However in the last years the new graphic cards and processors allow to directly map all graphic (peripherals, in general) memory to a common, shared virtual address space. This is the new frontier, and a 32-bit o.s. is clearly not able to work/use it, since todays graphic cards bring several GBs of memory.
This is also the reason why it doesn't make sense at all to continue talking and thinking about 32-bit o.ses nowadays: 64-bit is the new bare minimum target. |
Addressing space for graphics is the most compelling reason to support a 64 bit CPU and OS. However, the limit of portable and energy efficient graphics is usually achieved before needing 64 bit addressing. Few embedded applications need 64 bit CPUs as cheaper and more efficient 32 bit CPUs are here to stay. Supporting 64 bit for mid to high performance hardware and the future is important though. |
The embedded is different market segment, where 32-bit ISAs are still the most predominant. But for almost everything else, 64-bit is the way to go. Quote:
Quote:
This was already implemented in modern o.ses, which put part of the kernel memory mapped into the user/process memory, to speed up accessing both kind of memory depending on the execution mode (kernel accessing user memory, and viceversa).
And this lead to the infamous Meltdown security breach... However, even fixing Meltdown, some Spectre vulnerability allows to access kernel and even Hypervisor memory from the user land.
Unless we want to limit processors performances falling back to in-order microarchitecture designs, sharing in some way user and kernel memory is not recommended nowadays.
Unless we decide to ignore security, like we always did using the Amiga o.s.. |
I'm aware of how monolithic kernel's map their memory. I did *not* propose allowing user code to access supervisor space/pages as x86/x86_64 allows. I proposed limiting some user space code from accessing some user space memory in a very simple way. |
Can you make some example, if possible? Quote:
The Spectre and Meltdown type vulnerabilities have more to do with OoO speculation not paying the full cost of user/supervisor mode isolation. I don't think it is necessary to give up OoO altogether but less aggressive OoO and in order designs are likely to be more competitive now. This hurts RISC designs more than CISC designs. |
Less aggressive OoO makes sense, but in-order designs not anymore, unless we want to talk about specific market segments (embedded, low-power servers, server with high aggregate performances). Quote:
Quote:
Nevertheless, those beautiful "features" which Jason highlighted are also the big burden that the Amiga o.s. still carries on, and aren't desirable on mainstream systems... |
Yes, most CPUs were designed to support big monolithic kernels of Linux/BSD/Windows and responsiveness has suffered. |
Windows isn't monolithic: it uses a hybrid kernel, so with functionality spread over supervisor and user mode, depending on the specific needs/advantages. Quote:
I'm not willing to throw away the Amiga's beautiful features without looking into ways to make them more beautiful today. |
Well, if there are ways to implement modern, desirable features without giving up the Amiga o.s. structure I have nothing against. I simply doubt that it's possible to realize a mainstream o.s. this way. |
| Status: Offline |
| | cdimauro
| |
Re: Why was AmigaOS 4.X developed only for PowerPC? Posted on 17-Sep-2018 20:10:26
| | [ #585 ] |
| |
|
Elite Member |
Joined: 29-Oct-2012 Posts: 3621
From: Germany | | |
|
| @bison
Quote:
bison wrote: @cdimauro
Quote:
Microsoft lost the average Joe market several years ago, when Apple introduced the first iPhone, and then the first iPad. |
I would say that they are more in the process of losing it. They are definitely in decline. When people talk about big tech nowadays, it's usually Google or Apple, not Microsoft. |
Sorry, but I agree with Rose here. Quote:
Quote:
Now that market is dominated by smartphones and tables, and Microsoft had problems entering it. |
That's an understatement. They seem to have failed at almost everything since X-Box. They've got that Surface thing, but I've only ever seen that on Hawaii Five-O. |
Unfortunately the new CEO decided to exit from the mobile market, which was bad decision IMO, since Microsoft's mobile platform was growing and getting market share.
@kolla
Quote:
kolla wrote: @cdimauro
Quote:
Another possibility is moving the shared GUI/CLI code to a library, and offer separate GUI and CLI versions of the same application, with both using that library. |
The correct Amiga way - a library with a rich arexx interface that anyone can make GUI and CLI commands to. |
AREXX? Too old. I prefer Python.
|
| Status: Offline |
| | bison
| |
Re: Why was AmigaOS 4.X developed only for PowerPC? Posted on 18-Sep-2018 2:10:31
| | [ #586 ] |
| |
|
Elite Member |
Joined: 18-Dec-2007 Posts: 2112
From: N-Space | | |
|
| @cdimauro
Quote:
AREXX? Too old. I prefer Python. |
Same here. Lua is also popular as an embedded language, but I find it's lack of a continue statement inconvenient.
_________________ "Unix is supposed to fix that." -- Jay Miner |
| Status: Offline |
| | cdimauro
| |
Re: Why was AmigaOS 4.X developed only for PowerPC? Posted on 18-Sep-2018 4:49:00
| | [ #587 ] |
| |
|
Elite Member |
Joined: 29-Oct-2012 Posts: 3621
From: Germany | | |
|
| @bison That's the beauty and ugly of Lua: a very simple language with a very small footprint to implement/embedded, but that lacks tools which hart coders creativity/expressiveness. And that's why Python become the de-facto "script" (sigh!) language (you find it everywhere). |
| Status: Offline |
| |
|
|
|
[ home ][ about us ][ privacy ]
[ forums ][ classifieds ]
[ links ][ news archive ]
[ link to us ][ user account ]
|