@cdimauro

I understand "support" is not something you work with?
This idea that "Joe Regular" should be the target of any computer system, and that so called "experts" are to jump through all kinds of hoops and hinders to get jobs done, is nonsense.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

Quote:

What I want to say is that advanced users will find their way to run any applications that they like, but the opposite is unlikely be the case for the common users, so the default should be to favor them.

Sure, that's fine, but this isn't a valid argument against GUI apps that are front ends for command-line apps. If a so-called "normal" person clicks an icon on the desktop that happens to execute 'foo -g' and it runs 'foo' in GUI mode, they will not even know that a command-line version of 'foo' exists.

@kolla

Quote:

This idea that "Joe Regular" should be the target of any computer system, and that so called "experts" are to jump through all kinds of hoops and hinders to get jobs done, is nonsense.

Yeah, Microsoft already owns that market, and they can keep it as far as I'm concerned.

Last edited by bison on 02-Sep-2018 at 06:41 PM.

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

@kolla

Quote:

kolla wrote: @cdimauro I understand "support" is not something you work with?

Not exactly. Actually I'm a principal QA engineer, so only in some way we can talk about "support" and "customer orientation".
Quote:

This idea that "Joe Regular" should be the target of any computer system, and that so called "experts" are to jump through all kinds of hoops and hinders to get jobs done, is nonsense.

Indeed: this isn't what I said. The fact the target should be the average Joe doesn't automatically imply that experts should have hard ways to get what they want. Logic, eh!

The problem is that having limited resources maybe you cannot end up supporting both kind of users in the same way. If there's something to be sacrificed it shouldn't be the common user experience. But if you have plenty of resources, you can satisfy both...

@bison

Quote:

bison wrote: @cdimauro Quote: What I want to say is that advanced users will find their way to run any applications that they like, but the opposite is unlikely be the case for the common users, so the default should be to favor them. Sure, that's fine, but this isn't a valid argument against GUI apps that are front ends for command-line apps. If a so-called "normal" person clicks an icon on the desktop that happens to execute 'foo -g' and it runs 'foo' in GUI mode, they will not even know that a command-line version of 'foo' exists.

Fine for me. What counts is the end result.
Quote:

@kolla Quote: This idea that "Joe Regular" should be the target of any computer system, and that so called "experts" are to jump through all kinds of hoops and hinders to get jobs done, is nonsense. Yeah, Microsoft already owns that market, and they can keep it as far as I'm concerned.

Microsoft lost the average Joe market several years ago, when Apple introduced the first iPhone, and then the first iPad.

Now that market is dominated by smartphones and tables, and Microsoft had problems entering it.

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.

Quote:

The embedded market can be an interesting arena where an Amiga o.s. successor can play its cards, but it's necessary to lift it removing some bad designs and making it more general purpose (e.g.: not so explicitly bounded to the Amiga chipset). But this means losing backward-compatibility. Another important thing is that it should be more modular/scalable. Embedded is a vast territory where you very different needs. For example, you might not want/need a GUI/graphic subsystem. You may not want a pre-emptive multitasking. Sometimes you may not want an o.s. at all and run the main application like the o.s. main process/thread.

Yes, the AmigaOS needs improvements for the embedded market. It is already modular and scalable but there can't be too much of this for embedded.

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. The AmigaOS also makes some assumptions as can be seen by APTR's in structures.

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?

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, 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.

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.

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

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.

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.

Quote:

cdimauro wrote: A CISC cannot extend/apply any kind of possible operation to all instructions. There should be a balance, depending on how often/important/critical is the operation. Which is an obvious consideration, since we have opcode-space and transistor budgets to take care. Let's say that we want an ISA which allows to apply any combination of the following operations to all instructions: - LE or BE data access (as you were discussing); - zero extension of data coming from any size, up to the instruction size; - sign extension of data coming from any size, up to the instruction size; - non-temporal data access (e.g.: don't put the accessed data into the cache); - access to any part of a register when using a smaller size (e.g.: a 64 bit register has 8 8-bit registers, 4 16-bit registers, etc.); - flags updating inverter (e.g.: instructions which update flags don't do it anymore; instructions that don't update flags will do it); - access to thread local storage (TLS) in user mode, and to user memory in kernel/supervisor mode; - cut address size (e.g.: in 64-mode, cut any generated address to 32-bit). I stop here, because they are sufficient examples of operations which are very useful on particular kind of code, and will be good to have a way to apply any of those to all instructions, especially if selectable on per-instruction basis. Now imagine how an ISA should be organized to support all of those goodies, and how many transistors (and power budget as well) are required to implement it.

CISC can apply many different operations to longer encodings and even addressing modes. A CISC variable length encoding can encode *more* options than a 32 bit fixed length RISC encoding. The RISC ISA has already accepted reduced code density and needs increased functionality to offset the performance loss so more features are often seen here. I agree that it is not practical to encode a huge number of options so it is important to figure out which ones will give the most benefit. It is not impractical to have endian swapping load/store instructions for a 32 bit fixed length encoding as some architectures have them (for example, PPC lhbrx/sthbrx and lwbrx/stwbrx instructions). AArch64 has obviously decided that big endian support is less important today, which is true, but this decision makes it less attractive for Amiga use.

Quote:

Indeed. Out-of-order x64 processors usually can execute up to 2 MOVBE instructions per clock cycle. It should be enough for networking, emulation, and running an o.s. in big-endian "mode" as you were discussing. All this without the burden to implement at all ISA level (e.g.: all instructions affected) a LE/BE data access mode. Yes, it'll not be the best thing looking at the pure performance and at the code density, but it's a reasonable compromise for the specific purpose. Because an ISA cannot become a black hole, assimilating all possible needs.

Despite the "MOV" name in "MOVBE", x86_64 is using the CISC register-memory advantage to roughly double the endian conversion performance compared to AArch64. PPC abandons the RISC philosophy by doing data processing during load/store instructions.

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.

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. 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.

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. I'm not willing to throw away the Amiga's beautiful features without looking into ways to make them more beautiful today.

Last edited by matthey on 03-Sep-2018 at 12:47 AM.
Last edited by matthey on 03-Sep-2018 at 12:46 AM.

@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.

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.

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

@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.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@bison

Quote:

I would say that they are more in the process of losing it. They are definitely in decline.

Decline is prolly reason why their stock is at all time high after posting really nice quarter.

@Rose

they are changing their business model in cloud business

of course classical fields where they earned the money in the past are declining but still making profit

But the time of ever-rising sales in the smartphone/tablet market are over too. Most people who are interested in it have already such devices and spending 1000 Dollar for features you only need to impress "childs" is not a model for all time too.

Today younger people only have limited knowledge of IT so they are using "Apps" so if you want to gain users there you would need some kind of killer app.

For alternative platforms like Amiga there is not much room in this new world, the chance to get in mass market is zero. Most chances are if you support something like Raspberry that is used by people who are open and have technical knowledge...

@OlafS25

Quote:

they are changing their business model in cloud business of course classical fields where they earned the money in the past are declining but still making profit

Cloud was big earner but stories about death of traditional software side are bit premature.
"Windows OEM revenue increased 7%" also got to remember that sizable part of that cloud growth is Office 365.

Quote:

Today younger people only have limited knowledge of IT so they are using "Apps" so if you want to gain users there you would need some kind of killer app. For alternative platforms like Amiga there is not much room in this new world, the chance to get in mass market is zero. Most chances are if you support something like Raspberry that is used by people who are open and have technical knowledge...

It's not just young people. People in general aren't intrested about using operating system. They get computers to get shit done.

@Rose

I think there are differences in interests and behavior between the "generation smartphone" and the older ones because you were forced to be interested in the system when using one of the home computers. Today you have countless apps to solve a problem, it is more a problem to choose the right one. That is what most people do, choose a app. There is no interest in the system, in hardware or OS.

But be it, alternative platforms are nothing for that group

@OlafS25

And I was agreeing with you on that. "It runs operating system X" isn't as much a sales pitch than "I has app X and Y!".

To my mind, what AmigaOS runs on is irrelevant. Anybody who thinks it has any serious use case today beyond pandering to nostalgia is kidding themselves.

That's not to say I think continuing to develop the OS is pointless, it's not. Said nostalgics, myself included, enjoy using it and that's reason. I'm a bit sceptical of wanting to modernise the OS too much; you might as well just pick a modern multicore capable, protected memory OS and build some sort of compatibility layer for that. Amiga OS itself harks back to a different, cosier time when a single CPU was plenty, not every memory access was considered a potentially malicious attack, processes were allowed to share resources and a bad program taking down the OS was the program's fault and not the that of OS. Those times are long gone and retrofitting modern concepts to the OS would just turn it into a poor Linux clone with none of the original charm. Might as well just use Linux.

We all know why OS4 went PowerPC. That was basically a done deal as soon as expansion cards appeared with PPC processors on them. There was already a proven 68K to PPC migration with the PowerMac. PPC made sense because it was still in development, was big endian (simplifying a lot of things) and at the time still seemed relevant as a desktop CPU.

Migrating to PPC left most of the tricky stuff unchanged. We still have big endian memory and 32-bit pointers.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: To my mind, what AmigaOS runs on is irrelevant. Anybody who thinks it has any serious use case today beyond pandering to nostalgia is kidding themselves.

Yes, and to think there is a market outside of Amiga realm, just waiting to embrace 68k and AmigaOS?

There were quite a few legacy operating systems in embedded that suffered from the same and similar limitations to that of AmigaOS (Cisco IOS for example), but they have all slowly managed to crawl away from them. There is just no way they are going back to that.

Quote:

That's not to say I think continuing to develop the OS is pointless, it's not. Said nostalgics, myself included, enjoy using it and that's reason. I'm a bit sceptical of wanting to modernise the OS too much; you might as well just pick a modern multicore capable, protected memory OS and build some sort of compatibility layer for that.

Right. For me as a user, what makes Amiga worth while, is the user interface/experience - screens, public screens, menus on RMB, the multi-select macro-building in menus, the shell, the workbench/desktop, scriptability/program intercommunication that arexx provides etc etc. Nothing of this is strictly related to inner workings of AmigaOS and could be reimplemented with a modern, safe design.

For oldschool developers, this may not be interesting at all though :)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Karlos

Quote:

We all know why OS4 went PowerPC. That was basically a done deal as soon as expansion cards appeared with PPC processors on them. There was already a proven 68K to PPC migration with the PowerMac. PPC made sense because it was still in development, was big endian (simplifying a lot of things) and at the time still seemed relevant as a desktop CPU. Migrating to PPC left most of the tricky stuff unchanged. We still have big endian memory and 32-bit pointers.

And why it remained that way also involved:

Source

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@Rose

They're still making money, and will probably continue to do so for a while, but they haven't come out with anything very interesting in a long time. Windows 8.1 was damage control, and Windows 10 is more or less "we hope you'll forget about the Windows 8 debacle."

F# is kind of interesting, but that's about it.

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

@bison

Windows 7 is nice to use. All later iterations lost the plot and attempt try and get rid of traditional GUI made specifically for computers and shoe horn in a horrible phone-like UI. What are they thinking? I honestly can't use Windows 10 without the Shell Start Bar add on. And don't mention the updates or the file menu for MS Office programs (yes I said programs and not apps you read correctly) why is there so much space / pointless information? And why does every thing need a tile or a big colourful icon? THIS ISN'T A PHONE!!!!!!!

Last edited by BigD on 03-Sep-2018 at 05:31 PM.

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

@BigD

ReactOS is here to save you ;)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@number6

The time at which this was written makes the reasoning even more painful to revisit.

#1 certainly didn't prevent Hyperion from moving to make the OS more platform agnostic and #2, 3 & 4 now sound even more asinine.

Apple was confronted with an identical set of challenges and yet they found a way within a far more intractable market.

The Hyperion approach was likely determined by a handful of people who chose to ignore what Apple was doing and considered anything other than the PPC to be evil.

@ne_one

Every post is merely a snapshot in time.

This posting with links is more of a brief timeline that illustrates changes in thinking as time marched on:

Source

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@Karlos

Quote:

To my mind, what AmigaOS runs on is irrelevant. Anybody who thinks it has any serious use case today beyond pandering to nostalgia is kidding themselves.

I will agree on the architecture but since when has a serious use case determined market viability? You mean like the Hula hoop, Yo-Yo and Slinky?

Mainstream relevance has never been a benchmark for the success of the Amiga. Not in 1985 and certainly not now.

The people who controlled the platform and the brand had one simple challenge: use the Amiga to make money.

The tragedy is that in over 3 decades a whole raft of people have demonstrated that you can turn any venture into a failure if you apply enough incompetence and shadiness.