Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
19 crawler(s) on-line.
 158 guest(s) on-line.
 1 member(s) on-line.


 Gunnar

You are an anonymous user.
Register Now!
 Gunnar:  1 min ago
 pixie:  9 mins ago
 NutsAboutAmiga:  13 mins ago
 zipper:  49 mins ago
 Templario:  55 mins ago
 RobertB:  1 hr 14 mins ago
 GPTNederlands:  1 hr 29 mins ago
 janelancy:  1 hr 30 mins ago
 -Sam-:  1 hr 39 mins ago
 OlafS25:  2 hrs 22 mins ago

/  Forum Index
   /  Amiga OS4.x \ Workbench 4.x
      /  Why was AmigaOS 4.X developed only for PowerPC?
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 )
PosterThread
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
Profile     Report this post  
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
Profile     Report this post  
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:
Ben and me

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
Profile     Report this post  
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:
Take a look at Apple's A7 performances with 32 and 64 bit applications:
https://www.anandtech.com/show/7335/the-iphone-5s-review/4
As you can see, in many cases the gain is much bigger than 1%.

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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
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
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle