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
16 crawler(s) on-line.
 123 guest(s) on-line.
 2 member(s) on-line.


 Rob,  Beajar

You are an anonymous user.
Register Now!
 Beajar:  53 secs ago
 Rob:  3 mins ago
 DiscreetFX:  1 hr 6 mins ago
 agami:  1 hr 6 mins ago
 RobertB:  1 hr 26 mins ago
 OlafS25:  2 hrs 16 mins ago
 Bruce72:  2 hrs 17 mins ago
 MEGA_RJ_MICAL:  3 hrs 5 mins ago
 t0lkien:  3 hrs 10 mins ago
 amigakit:  3 hrs 31 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 Next Page )
PosterThread
kolla 
Re: Why was AmigaOS 4.X developed only for PowerPC?
Posted on 16-Aug-2018 13:23:02
#541 ]
Elite Member
Joined: 20-Aug-2003
Posts: 2859
From: Trondheim, Norway

@bison

Quote:

Commodities are a very useful feature. One thing that I'm not certain of is if they can be implemented in a secure way. It seems like a very opportune way for someone with malicious intent to pass information along to a program that shouldn't be getting it, or to get information from a program that shouldn't be giving it.


I don't see what this has to do with the commodity interface, which is standardised and limited in what it can do (show, hide, quit). That is more a problem with ARexx, which can accept any kind of input and do whatever.

Last edited by kolla on 16-Aug-2018 at 01:24 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

 Status: Offline
Profile     Report this post  
Hypex 
Re: Why was AmigaOS 4.X developed only for PowerPC?
Posted on 17-Aug-2018 13:58:38
#542 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@matthey

Just touching on this for now.

Quote:
Yes, 64 bit and 32 bit little endian without an instruction like ARM's SETEND will make 68k compatibility much less inefficient although the performance could be offset by much higher performance x86_64 CPUs than PPC CPUs.


x86/64 already has implicit and specific big endian support with the BSWAP and MOVEBE instructions so there is no excuse. Compilers are still playing catch up. AFAIK standard C/++ still does not support rotation even which has been in CPU instruction sets since time immemorial. So no surprises big endian data types are still not supported.

I don't think it's good enough to use shifts and masking. That is like doing A to achieve B as a result, instead of exactly specifying B in the code. Such methodology is usually looked down on. And compilers can't be trusted to look at what your doing with every edge case and figure out a one man instruction that will do it all.

Quote:
AmigaOS 4 with minor changes could probably do the same on a 64 bit PPC CPU. Is it really worth it for a few hundred users though.


There is the extended memory feature.

Quote:
Message passing could be trapped and copied by the trap code which would provide security but would be the slowest way to pass messages.


Why does it need to be trapped? All messages passing through the standard message passing system go through PutMsg(). It's a case of do not pass GO until it goes through PutMsg().

What to do with the contents is another question. Since you've got a dataload or payload of unknown variables and pointers. And it's a bit hard to change addresses to handles and hide the technical location.

PutMsg() can be very sensitive to touch. In the 1.3 days I experimented with it. And one false move would lock up the OS. But I rather like the message passing system. It's what made AmigaOS efficient. Even if it was changed to copy on send would it be of much benefit except to slow it down? And what is the problem with sharing messages? Even copying a message would have pointers. Do they avoid this by using UUID handles or some other method?

Quote:
You don't use ARexx? I wish it was possible to turn off 68k emulation and then we would see.


JIT can be turned off but 68k is still in Exec. So I think a patch would need to be written that gives error when a 68K executable is loaded in or disable the emulating method.

 Status: Offline
Profile     Report this post  
matthey 
Re: Why was AmigaOS 4.X developed only for PowerPC?
Posted on 18-Aug-2018 2:04:23
#543 ]
Super Member
Joined: 14-Mar-2007
Posts: 1968
From: Kansas

Quote:

Hypex wrote:
x86/64 already has implicit and specific big endian support with the BSWAP and MOVEBE instructions so there is no excuse. Compilers are still playing catch up. AFAIK standard C/++ still does not support rotation even which has been in CPU instruction sets since time immemorial. So no surprises big endian data types are still not supported.


MOVBE is 2 bytes longer than MOV (minimum of 4 bytes but more if a 64 bit operation or using r8-r15). CISC should be able to do an operation at the same time.

Let's look at a simple case of adding a 32 bit number in memory to a number in a register.

risc_noswap:
lw r0,(r2) ; 4 bytes
add r0,r0,r1 ; 4 bytes
total: 2 instructions, 8 bytes of code, 3 registers used

cisc_noswap:
add.l (a0),d0 ; 2 bytes
total: 1 instruction, 2 bytes of code, 2 registers used

cisc_movbe:
movbe (r2),r0 ; 4 bytes
add r1,r0 ; 2 bytes
total: 2 instructions, 6 bytes of code, 3 registers used

cisc_bswap:
mov (r2),r0 ; 2 bytes
bswap r0 ; 3 bytes
add r1,r0 ; 2 bytes
total: 3 instructions, 7 bytes of code, 3 registers used

Now incrementing a variable in memory by one.

risc_noswap:
lw r0,(r2) ; 4 bytes
add r0,r0,1 ; 4 bytes
stw r0,(r2) ; 4 bytes
total: 3 instructions, 12 bytes of code, 2 registers used

cisc_noswap:
addq.l #1,(a0) ; 2 bytes
total: 1 instruction, 2 bytes of code, 1 register used

cisc_movbe:
movbe (r2),r0 ; 4 bytes
add $1,r0 ; 3 bytes
movbe r0,(r2) ; 4 bytes
total: 3 instructions, 11 bytes of code, 2 registers used

cisc_bswap:
mov (r2),r0 ; 2 bytes
bswap r0 ; 3 bytes
add $1,r0 ; 3 bytes
bswap r0 ; 3 bytes
mov r0,(r2) ; 2 bytes
total: 5 instructions, 13 bytes of code, 2 registers used

Using MOVBE may not be too much worse than inefficient RISC but the advantages of CISC are lost (reduced instruction count, better code density, smaller instructions, fewer registers used and reduced memory traffic). Endian swapping all the time is a big penalty on the x86_64 (porting a whole AmigaOS but using all big endian data for compatibility) even though most modern x86_64 CPUs are probably going to outperform any available PPC CPU while doing it.

There are the GCC __builtin functions/macros __builtin_bswap16(), __builtin_bswap32(), __builtin_bswap64().

https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

I created a __builtin_ link library for vbcc compatibility with the GCC __builtin_ functions.

http://eab.abime.net/showthread.php?t=82114

Quote:

I don't think it's good enough to use shifts and masking. That is like doing A to achieve B as a result, instead of exactly specifying B in the code. Such methodology is usually looked down on. And compilers can't be trusted to look at what your doing with every edge case and figure out a one man instruction that will do it all.


Rotate instructions are generated by compilers with targets that support them. Some compilers will recognize some common sequences which translate to rotates but this is inconsistent and varies from compiler to compiler. The problem is that there is currently no way to specify rotates in C. SAS/C had functions for rotates in their __builtin_ library which was added to the Amiga right before their support stopped. I considered adding them to my vbcc __builtin library but they are a little tricky to support as the number of args can vary. It's not like my project generated much interest as the Amiga is dead and my banning from EAB put the final nail in the coffin. The C standards committee could have easily added functions or operators for rotates. I know some developers were asking for them especially embedded developers.

Quote:

Quote:
AmigaOS 4 with minor changes could probably do the same on a 64 bit PPC CPU. Is it really worth it for a few hundred users though.


There is the extended memory feature.


The PPC equivalent of PAE/LPAE? Sure. I have heard 64 bit PPC code is much bigger and slower so this probably helps with that. I wonder how well it works with the AmigaOS 4 gfx drivers using high end gfx cards needing lots of address space?

Quote:

Why does it need to be trapped? All messages passing through the standard message passing system go through PutMsg(). It's a case of do not pass GO until it goes through PutMsg().

What to do with the contents is another question. Since you've got a dataload or payload of unknown variables and pointers. And it's a bit hard to change addresses to handles and hide the technical location.


The problem is the shared memory.

1) Once memory is shared it is difficult for the memory to go away or be freed.

Say task A sends a message to task B. If task A crashes then no shared memory can be freed until the message is replied (cleanup code needs to wait for the message reply). If task B crashes then all messages at the receiving message port need to be replied. Both cases require good resource tracking and smart cleanup code. This should work but there has not been enough restrictions on what can and can't be done with messages in the past so full compatibility is not possible. Perhaps disallowing pointers in messages (but allowing more than 64kiB) would be a good restriction to add. The AmigaOS needs to know more about what shared memory is being used for and by which tasks in order to free shared memory and all resources.

2) Shared memory can be accessed by any task which is a security risk.

This is the tricky part. It is possible to have messages, message ports and even libraries in supervisor memory which are not visible to everyone but resources in supervisor memory can't safely access user level resources and user level resources must trap/switch to supervisor mode to use supervisor resources. There is a hard wall/barrier between user and supervisor mode. The AmigaOS primarily uses user mode which is performance efficient but is almost like not having a supervisor mode at all. I don't think this security problem can be solved without custom hardware including a custom MMU. I propose a superuser mode (user->superuser->supervisor->hypervisor) with a MMU setting in page tables. Superuser marked memory would trap to supervisor mode if accessed in user mode but not in superuser mode. All MMU tables could only be changed in supervisor mode. All memory and resources which can do something dangerous would be allocated with superuser marked memory. A switch to supervisor mode would be required to check for authorization (perhaps a password) but then programs could operate in user/superuser mode most of the time without the overhead of switching to supervisor mode. Most programs wouldn't be aware of whether they are in user or superuser mode although a quick user level check of a flag could avoid some traps to supervisor for security aware programs. This would effectively add a fast and compatible supervisor mode to the Amiga without much of the overhead of switching to supervisor. I believe it would require minimal changes to current MMU designs and would be compatible with other operating systems. This would be a good idea to run past ThoR if the Amiga situation was not such a mess.

Quote:

PutMsg() can be very sensitive to touch. In the 1.3 days I experimented with it. And one false move would lock up the OS. But I rather like the message passing system. It's what made AmigaOS efficient. Even if it was changed to copy on send would it be of much benefit except to slow it down? And what is the problem with sharing messages? Even copying a message would have pointers. Do they avoid this by using UUID handles or some other method?


Jason McMullan summoned up the AmigaOS efficiencies pretty well in an interview.

Quote:

Some of the AmigaOS advantages I like are things like:

o No system call overhead.
o Message passing by reference (instead of copying the entire message packet via a pipe or FIFO).
o User-level interrupt handlers.

But these advantages are solely possible by the biggest disadvantage of AmigaOS and AmigaOS derived operating systems - minimal to nonexistent memory protection, and a single-CPU architecture. Pavel Fedin is working on better MMU and SMP support for AROS, and I wish him the best of luck. The underlying AmigaOS architecture make this a very interesting problem.

Not to mention learning m68k assembly, which I had not been exposed to before last fall (2010).

Also, I would like to say that MorphOS and AmigaOS could benefit from opening up their source code - people such as myself are often looking for an interesting challenge to their programming skills, and releasing some of their kernel and library sources could help develop more interest (and ports to other hardware!) of their systems.


That is coming from a POSIX/Unix guy! I left in the last part because hiding away the AmigaOS and only targeting a niche market is killing the Amiga. Jason's talent should never have been allowed to walk away from the Amiga but this is typical of the kind of talent that has become discouraged and left. Can we retain the Amiga philosophy and leverage the Amiga's advantages with creativity or do we emulate inefficient operating systems? Full creativity and good compatibility requires custom hardware and we need it to be mass produced and affordable!

Quote:

JIT can be turned off but 68k is still in Exec. So I think a patch would need to be written that gives error when a 68K executable is loaded in or disable the emulating method.


Leaving the 68k JIT in Exec gives an indication of how important 68k compatibility is to AmigaOS 4.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Why was AmigaOS 4.X developed only for PowerPC?
Posted on 22-Aug-2018 7:01:57
#544 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@Hypex

The comments about rotate instructions remind me of the fun I had with StormGCC years ago

https://github.com/0xABADCAFE/ancient-amigaos-exng2/blob/master/include/platforms/amigaos3_68k/systemlib/machine_bitops_native.hpp

As horrible as that code looks, the inlined template code would emit the best assembler it could, taking into consideration the word size, rotate size and whether or not the amount being rotated by was a compile time constant or a runtime value.

Note that all the bloated if/else code that is basically evaluated at compile time and is not emitted on template invocation. So while it looks like I might be shifting and masking to rotate a value, that only happens when the value is a compile time constant.

Last edited by Karlos on 22-Aug-2018 at 07:09 AM.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
matthey 
Re: Why was AmigaOS 4.X developed only for PowerPC?
Posted on 22-Aug-2018 23:28:31
#545 ]
Super Member
Joined: 14-Mar-2007
Posts: 1968
From: Kansas

Quote:

Karlos wrote:
The comments about rotate instructions remind me of the fun I had with StormGCC years ago

https://github.com/0xABADCAFE/ancient-amigaos-exng2/blob/master/include/platforms/amigaos3_68k/systemlib/machine_bitops_native.hpp

As horrible as that code looks, the inlined template code would emit the best assembler it could, taking into consideration the word size, rotate size and whether or not the amount being rotated by was a compile time constant or a runtime value.

Note that all the bloated if/else code that is basically evaluated at compile time and is not emitted on template invocation. So while it looks like I might be shifting and masking to rotate a value, that only happens when the value is a compile time constant.


I'm kind of surprised you didn't switch to using the immediate form of rotate when the constant is less than or equal to 8 as It is a little faster on some 68k CPUs like the 68040 (3 cycles instead of 4). The code looks really good though. I take it you used swap32() and swap64() because GCC's __builtin_bswap32() and __builtin_bswap64() did not exist yet?

The SAS/C rotate functions were introduced in version 6.58.

Quote:

x = __builtin_rol(a, b, size);
x = __builtin_ror(a, b, size);

where

x is the result of 'a' rotated by 'b' bits.
size is an optional constant parameter where
size = 0 - byte size rotate
size = 1 - word size rotate
size = 2 - long size rotate (default size if arg is omitted)
if size is omitted, size is assumed to be a long.

NOTE: if 'b' is a constant value 16, and long size is to be used, then a SWAP instruction will be generated.


My vbcc __builin_ link library can only use C standards but there is no functionality like __builtin_constant_p(). My library itself can't support some functions like __builtin_constant_p() as it would need information internal to the compiler. The SAS/C rotate functions allowing to omit the 3rd argument makes supporting them properly even trickier.

@all
The superuser (user) mode idea I came up with is a very efficient form of protection ring.

https://en.wikipedia.org/wiki/Protection_ring

Most MMU page tables only have user or supervisor privilege bits so it would require 1 more bit which could allow hypervisor memory protection at the same time (it is surprising this has not been added already). The 2nd user mode could avoid switching to supervisor mode or using messaging for kernel functions. The overhead of a CPU mode switch to supervisor mode is significant (pipeline flushed, several memory accesses) taking roughly 10 times longer than a user mode subroutine on modern hardware. An inferior vDSO kludge was added to avoid this overhead.

https://en.wikipedia.org/wiki/VDSO
http://arkanis.de/weblog/2017-01-05-measurements-of-system-call-performance-and-overhead

I'm going to start talking to various people about these ideas as I investigating patents for this as well as the single bit in a 64 bit address used to indicate a physical vs virtual address thus avoiding TLB lookups. The AmigaOS is a simpler design than most modern OSs which started and grew up differently. Simple hardware design changes could change some of her disadvantages to advantages. I'm talking high performance, low jitter and low latency decisions especially for a 64 bit architecture. Think tiny footprint embedded RTOS and low latency gaming. Other microkernel OS designs like QNX, L4 (MorphOS is adapting for their kernel) and Integrity are embedded in *billions* of devices as the AmigaOS continues to target a few thousand desktop users. Sigh.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Why was AmigaOS 4.X developed only for PowerPC?
Posted on 23-Aug-2018 6:39:53
#546 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@matthey

Immediate forms are used when the shift value is constant. In the first rotate byte template you will note that when bits is constant, we mask off the lower 3 bits and emit a rotate instruction where the asm() input predicate for bits is I and not d. This results in a rol.b #(bits&7), val for that. Unless of course the effective rotate size is zero, then no statement is issued at all.

I wrote test code for all these operations and scrutinised the assembly output to ensure they were doing what I wanted. It's possible I missed some case though, the code can be gnarly.

At the time I wrote this, the built-in support for byte swapping didn't seem to exist. Storm GCC was a 2.95 derivative.

A final point to note is that all these functions are inline templates and do not result in a specific function being generated (unless you try to take the address of one). Rather they just result in a short bit of inlined assembly being injected in the source unit they are being called from. Where this happens, the input predicates ensure the compiler is in charge of which registers are used for the value operands so as to not to limit it's ability to optimise through the code generated around the assembler insert.

I remember it working pretty well.

Last edited by Karlos on 23-Aug-2018 at 07:11 AM.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
matthey 
Re: Why was AmigaOS 4.X developed only for PowerPC?
Posted on 23-Aug-2018 20:25:22
#547 ]
Super Member
Joined: 14-Mar-2007
Posts: 1968
From: Kansas

Quote:

Karlos wrote:
Immediate forms are used when the shift value is constant. In the first rotate byte template you will note that when bits is constant, we mask off the lower 3 bits and emit a rotate instruction where the asm() input predicate for bits is I and not d. This results in a rol.b #(bits&7), val for that. Unless of course the effective rotate size is zero, then no statement is issued at all.


Ah. Makes sense although it is unnecessarily difficult to read without the '#' with the asm instruction (not your fault).

Quote:

I wrote test code for all these operations and scrutinised the assembly output to ensure they were doing what I wanted. It's possible I missed some case though, the code can be gnarly.


Finding enough Amiga developers and testers is a major problem these days. Code quality has really declined because of it.

Quote:

At the time I wrote this, the built-in support for byte swapping didn't seem to exist. Storm GCC was a 2.95 derivative.


The endian swapping functions are not even in the last unofficial 68k GCC 3.4.0 version either. This was one of the motivations behind adding my __builtin_ support to vbcc. I maybe could have added to the early versions of GCC as well with some tricks and surely by changing the function names completely. It would be great if we could get Bebbo's GCC environment running on 68k machines but it would probably be rather slow even on emulated 68k Amigas. It is so much more fun developing on an Amiga even if it is a little on the slow side. That's why I like vbcc with vasm where I can compile the compiler and assembler on my Amiga (3000T with CSMKIII 68060@75MHz). It just needs to be more GCC compatible in a modular way which is the idea behind my __builtin_ link library.

Quote:

A final point to note is that all these functions are inline templates and do not result in a specific function being generated (unless you try to take the address of one). Rather they just result in a short bit of inlined assembly being injected in the source unit they are being called from. Where this happens, the input predicates ensure the compiler is in charge of which registers are used for the value operands so as to not to limit it's ability to optimise through the code generated around the assembler insert.


My __builtin_ link library also has an include file which will use faster macros with CPU specific optimizations if included. The assembler inlines are similar to other vbcc assembler inlines in include files (used by default when included). Vbcc's inline assembler format is easier to read than with GCC but the compiler can't optimize as well around the inlined code. I suggested adding compatibility to GCC's assembler inline support to Frank Wille but it would be a lot of work.

It's sad to see another dead Amiga project with so much work in it. Only Amiga makes it impossible.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Why was AmigaOS 4.X developed only for PowerPC?
Posted on 23-Aug-2018 21:49:30
#548 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@matthey

Yeah, I loved vbcc and vasm too for C and C99 work. Somewhere else is another crazy library built around it as an experiment. I have never enjoyed coding as much as I did on the Amiga. I say did because I barely even switch one on nowadays.

StormGCC was full of weird issues that were actually kinda fun to work around. There's all sorts of weird things in that codebase to keep executable size down and improve code performance.

The fact it supported the asm() construct well allowed a lot of leeway when it came to these tricks.

Last edited by Karlos on 23-Aug-2018 at 09:54 PM.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Why was AmigaOS 4.X developed only for PowerPC?
Posted on 1-Sep-2018 20:03:08
#549 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@kolla

Quote:

kolla wrote:
@cdimauro

Quote:

Then we need new applications as well. You can recycle most of the code, but a new Amiga o.s. with all modern features is and works quite different from the current one (and successors/reimplementations).
Yes - and that is perfectly fine.

And yes, new applications too. The entire point is to have a platform that keeps the user interface/experience concepts and elements that Amiga _users_ are familiar with (screens that can have different resolutions, a souped up workbench, properly implemented amiga CLI, consistency between CLI and GUI, etc), yet a modern core and an operating system with all the features needed for the modern world, so that software developers - not Amiga developers, but _software developers_ - with as little effort as possible, can build their software for it.

With this mostly user-oriented perspective you don't need an Amiga o.s, but a desktop environment which resembles/works like it (running on top of any other modern/mainstream o.s).

A possibility here can be AROS hosted.

Regarding screens working on different resolutions, this isn't possible anymore. This was a feature of the PAL/NTSC video signal, whereas nowadays we have monitors which can be set/sync to different resolutions which aren't perfectly compatible each other (PAL/NTSC screens were all integer multiples of the "base" resolution, which was 320x256 or 320x200).
Something similar to the Amiga video screens can be simulated using composition. We have 3D video cards nowadays which can easily treat 2D screens like textures that can be "zoomed" & "translated" and put into the framebuffer.

@bison

Quote:

bison wrote:
@cdimauro

Quote:
Then we need new applications as well. You can recycle most of the code, but a new Amiga o.s. with all modern features is and works quite different from the current one (and successors/reimplementations).

I think so. It should run existing Amiga applications via emulation, Linux applications via a nested X-server, and new applications that are unencumbered by the requirements of existing Amiga and Linux applications. So the first day it is released it should have a large number of existing Amiga and Linux applications, and new applications that are being written using a new API that doesn't carry forward the mistakes of the past. (Or in the case of Linux, on mistakes that are still being made.)

Why do you need to run Linux applications? Linux is quite different from the Amiga o.s., and an NG Amiga o.s. will likely do not implement a fork API, which is heavily used in a Unix-like o.s.. Paradoxically, Windows is more similar to Amiga o.s. (it has no fork; at least in the Win* subsystems) and... has more software too.
@bison

Quote:

bison wrote:
@kolla

Quote:
...consistency between CLI and GUI...

I like the idea of a GUI application that is nothing but a front-end for a terminal app. The terminal app has to be written with hooks in it to make this seamless, but the same code (other than UI-specific code) is executed in either case.

Not all applications lend themselves to this approach, but I think it's natural for configuration utilities. For example, running 'foo' at the command line should take command line arguments, and running 'foo -g' should start the GUI version of the same application.

Frankly, I don't subscribe it at all. Amiga was born without a terminal: it was a GUI-based o.s. from the very beginning, and we, as users, were (and are, I hope) used to interact mostly with the Workbench, windows, icons, and... running GUI applications.
Yes, we had the CLI/shell and the possibility to run "CLI-only" applications, but this was not so common, and basically more for advanced users.
So, for me the default should be GUI applications, with CLI ones being just exceptions.

P.S. Sorry for the late answers, but I've bought an house, and in the last weeks I was (and still am, albeit I'm taking a break this weekend: I need to relax a bit) busy moving... -_-

 Status: Offline
Profile     Report this post  
utri007 
Re: Why was AmigaOS 4.X developed only for PowerPC?
Posted on 1-Sep-2018 20:20:55
#550 ]
Super Member
Joined: 12-Aug-2003
Posts: 1074
From: United States of Europe

@mods

I suggest that if anyone ever start new thread why not x86, ARM, or OS should be ported to x86, ARM, etc. etc it would be merged to this thread.

This way all b*llSh't would be in same place.

Last edited by utri007 on 01-Sep-2018 at 08:21 PM.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Why was AmigaOS 4.X developed only for PowerPC?
Posted on 1-Sep-2018 21:04:32
#551 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@matthey

Quote:

matthey wrote:
Quote:

cdimauro wrote:
I don't know about 3.9, but until Amiga o.s. 3.5 there's no MEMF_SHARED flag defined (hence, usable) for memory allocation: include/exec/memory.h

So, there's no 68K binary which is using it, and no source code which can be updated with many applications.

I think that it was also quite normal to use MEMF_PUBLIC for memory allocations, which makes it quite hard to introduce proper protection and/or support to the virtual memory (public memory is not swappable, AFAIK).

What's your plan to improve this situation?


MEMF_SHARED is new. MEMF_PUBLIC has been around (and abused) for a very long time.

http://wiki.amigaos.net/wiki/Obsolete_Exec_Memory_Allocation

Both of these flags should be respected which means that the shared/public memory can't be freed after a crash. MEMF_SHARED is more friendly and at least allows shared memory to be swapped out after a crash saving physical address space. Memory protection and resource tracking is better than turning it off in either case. Crash recovery with partial resource recovery is better than no crash recovery with no resource recovery. A 64 bit address space would make the loss of physical and virtual address space not a concern. Some kind of new API would likely need to be created to allow for all shared memory to be freed after a crash (existing programs would not benefit). I'm thinking it would be possible to allow shared memory messages instead of copying with a new API but it would be tricky.

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).
Quote:
Quote:
Just to clarify, do you think that losing compatibility with the existing Amiga o.s. applications is fine when talking about a new, modernized, Amiga o.s.?


It depends on the goal of the AmigaOS. If moving to an alien architecture and trying to compete with feature rich and mature operating systems then yes but realize that taking market share is an uphill battle even when their features are matched because of lack of software. I would prefer to aim lower end, smaller and more efficient where feature rich OSs can't go but embedded needs to go. Maybe it is possible to add features and retain software compatibility here. Don't underestimate the importance of software whatever the goal!

I don't, in fact: see above.

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

sizeof(APTR) should be enough to solve any problem without requiring a new pointer type.

C programs should use sizeof(APTR) but that doesn't help compatibility in AmigaOS structures when redefining APTR's size. Perhaps you mean to break compatibility though.

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.
Quote:
Quote:
Not if c stdlib memory pool uses public memory: it should be "kosher enough", since messages will be public, as expected/required.
And you cannot expect that C/C++/Pascal (Delphi)/etc. applications, which normally use their memory pools, will all be changed in order to use a specific o.s. API for doing a common task, like allocating memory; think also to C++ with its new operator and you'll get crazy thinking about such changes.

I wouldn't use malloc for allocating AmigaOS structures and I don't recommend it. Programmers should not count on malloc allocated memory to be MEMF_PUBLIC or any other type. You are asking for trouble if you do as your code will not be portable from one C compiler to the next and may break if AmigaOS memory protection is improved.

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..
Quote:
Quote:
However, and as I've already pointed out, the problem stays in the existing applications, which likely use MEMF_PUBLIC for all memory allocations, despite if the memory will be really used as public or not (private; only used by the application).
MEMF_PUBLIC is no doubt long abused as there has not been enough to break the programs that abuse it.

Then we must accept it as is. Which means that many Amiga applications will pollute the memory with not-good-enough allocations.
Quote:
Quote:
Not only few: there are many cases, common cases, where using 64-bit integers help a lot and improve performance. Memory copy/move/fill/scan/comparisons, string operations (not so well with the C str type, but 64-bit can be used as well with some tricks), decimals (fixed precision), color space conversions (32x32 bit multiplication -> 64-bit result), etc. I stop here but I can find others.
I can't remember where I saw the benchmark of 32 bit vs 64 bit compiled software results for a suit of benchmarks (not x86 vs x86_64 where 8 needed registers were added). On average the 64 bit applications were slower.

Yes. It usually happens if the only difference in the ISA is the increase pointers size.
Quote:
There are algorithms which are much faster with 64 bit but most applications are a little slower with 64 bit (slower mul, div and shift, worse code density, more DCache stress, bigger misalignment penalties).

True. The problem here is represented by the applications: if they don't better use the 64 bits data where they can, then they penalize the execution speed on such processors.
Quote:
AArch64 has 32 bit operations for this reason (helps low end CPUs more). It's kind of like 16 vs 32 registers where 32 can give a big boost to a few algorithms but I've seen results on benchmark suits where on average the performance gain is less than 1%. Register args instead of stack args with aggressive function inlining (GCC -O2 or higher), less than 1% performance gain too.

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%.
Quote:
Quote:
Not really: big pointers allow also pointer-tagging, which is very useful for managed resources (which are quite common today).

Ugh. We cleaned up 32 bit dirty programs when we ran out of 32 bit address space so now we allow 64 bit dirty programs?

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.
Quote:
I thought it would be interesting for the high bit of 64 bit addresses to be 1 to specify a physical or virtual address avoiding a TLB lookup. The big advantage would be to avoid TLB cache misses and allow the TLB cache sizes to be reduced in an OS where many of the addresses were physical addresses.

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).
Quote:
Quote:
This is common. AFAIR the default entry point for 64-bit applications is >4GB on Windows.

The default code model for x86_64 is small code which requires programs to reside in the lower 2GB of (virtual) memory because RIP (PC) relative addressing is only 32 bits.

https://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models

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.
Quote:
Quote:
The big problem is: who will update such applications, and how? See above.

Probably nobody with a niche Amiga market.

Then what we are talking about? :-/
Quote:
Quote:
Hum. AFAIR memory protection is only applied to not used/free memory pages, and you don't need to create a full page table hierarchy for it (keep only the entries & page directories which contain valid, allocated/used, pages).

I agree that there shouldn't be too much MMU overhead for as little of memory protection as AmigaOS 4 has. My 68060 Amiga with MMU library active doesn't need much memory. The 40%-50% worse code density of PPC than 68k can't explain it either. Neither the much larger stack needs of the PPC. I expect disc caches are bigger but my 68060 Amiga has plenty of memory to spare with generous caches.

There should be other factors which raised so much the base memory used. I've took a look at the other thread where it's being discussed.
Quote:
Quote:
They are still there, and without resource tracking every leak will worse the situation.

Imagine what happens with modern browser (which are affected by memory leaks). At least on a modern o.s. you can close and reopen the browser, solving such problems. With the Amiga o.s., it can only worse the situation...

The AmigaOS has memory pools. Freeing a memory pool gives back all the memory allocated within at once. The total memory I lose from memory leaks over time is usually not a problem. The performance degradation is a bigger concern because the CPU is not fast. The newer AmigaOS functions are much better at reducing fragmentation but are also slower on an unfragmented system. TLSFMem gives significantly faster memory functions and low fragmentation despite the relatively slow BFFFO instruction on the 68060 (the Apollo Core BFFFO is a fraction of the cycles).

Yes, they reduce the fragmentation and those instructions help a lot the performances, but this the problem is not solved, and running applications over applications will land to a very fragmented memory arena.
Quote:
Quote:
How, since usually you have public memory allocations, which aren't swappable?

Not all allocations are MEMF_PUBLIC. Program sections/hunks should be swappable at least. It sounds like virtual memory swapping is working in AmigaOS 4 but I can't say how good it is. The 68k has virtual memory add-ons like GigaMem, VMEM and XMEM. GigaMem worked reliably but did use a whitelist/blacklist setup for best compatibility. Perhaps some MEMF_PUBLIC flags were corrected from bug reports by virtual memory users.

I don't know how much it was done. My feeling is that most of Amiga applications just used MEMF_PUBLIC.

Black/whitelisting applications can be a possibility, but the real problem to solve is intercepting specific AllocMem calls in the code, and removing the MEMF_PUBLIC flag only there. But it's a very big task...
Quote:
Quote:
Eh. Quite hard to accomplish, since you don't know how the applications are using their resources...

It is not necessary to know how resources are used in order to track them.

Well, if you have MEMF_PUBLIC allocations you don't know if they where shared or not with other applications...
Quote:
Quote:
What do you mean here? Backdoors inside o.ses, or public access to collected data?

Fiber optic lines run to the NSA. They collect data in bulk but need secret court approval for searches and what filters can be used (broad search warrants are supposed to be Unconstitutional). Foreigners get less "security" than U.S. citizens.

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.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Why was AmigaOS 4.X developed only for PowerPC?
Posted on 1-Sep-2018 21:07:22
#552 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@utri007

Quote:

utri007 wrote:
@mods

I suggest that if anyone ever start new thread why not x86, ARM, or OS should be ported to x86, ARM, etc. etc it would be merged to this thread.

This way all b*llSh't would be in same place.

That's b*llSh't ONLY for you that have no clue at all about such technical discussions.

Then I suggest you to don't even open them: it's not bread for your teeth.

 Status: Offline
Profile     Report this post  
bison 
Re: Why was AmigaOS 4.X developed only for PowerPC?
Posted on 1-Sep-2018 22:50:09
#553 ]
Elite Member
Joined: 18-Dec-2007
Posts: 2112
From: N-Space

@cdimauro

Quote:
@bison

Quote:
I think so. It should run existing Amiga applications via emulation, Linux applications via a nested X-server, and new applications that are unencumbered by the requirements of existing Amiga and Linux applications. So the first day it is released it should have a large number of existing Amiga and Linux applications, and new applications that are being written using a new API that doesn't carry forward the mistakes of the past. (Or in the case of Linux, on mistakes that are still being made.)

Why do you need to run Linux applications?

For any new system to be successful it needs applications. If it has Chrome, Firefox, LibreOffice, Blender, Audacity, etc. at release, it has a much better chance of success than if it has none of these.

Quote:
@bison

Quote:
I like the idea of a GUI application that is nothing but a front-end for a terminal app. The terminal app has to be written with hooks in it to make this seamless, but the same code (other than UI-specific code) is executed in either case.

Frankly, I don't subscribe it at all. Amiga was born without a terminal: it was a GUI-based o.s. from the very beginning, and we, as users, were (and are, I hope) used to interact mostly with the Workbench, windows, icons, and... running GUI applications.

This sounds like a classic case of "but we've always done it this way."

There's no reason that it shouldn't have both; one doesn't have to replace the other. CLI configuration makes it easier to admin a system since things can be scripted.

The reason to have GUI apps that are front-ends to CLI apps is so that the code doesn't drift and you end up with a CLI version of an app that does things that the GUI version doesn't, and vice-versa. (Or even worse, one does it in a slightly different way than the other.)

Last edited by bison on 01-Sep-2018 at 11:02 PM.
Last edited by bison on 01-Sep-2018 at 10:56 PM.

_________________
"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 2-Sep-2018 5:26:23
#554 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@bison

Quote:
bison wrote:
@cdimauro
Quote:
Why do you need to run Linux applications?

For any new system to be successful it needs applications. If it has Chrome, Firefox, LibreOffice, Blender, Audacity, etc. at release, it has a much better chance of success than if it has none of these.

Then why not running Windows application, as I stated before? All applications that you listed are available for Windows, and... even more. With the plus thing that Win32 APIs have no fork() syscall, like all Unix-like o.ses, so it's easier to make Windows applications run on an Amiga/like o.s.. Running Linux applications is way more difficult due to the fork.
Quote:
Quote:
Frankly, I don't subscribe it at all. Amiga was born without a terminal: it was a GUI-based o.s. from the very beginning, and we, as users, were (and are, I hope) used to interact mostly with the Workbench, windows, icons, and... running GUI applications.

This sounds like a classic case of "but we've always done it this way."

There's no reason that it shouldn't have both; one doesn't have to replace the other. CLI configuration makes it easier to admin a system since things can be scripted.

The reason to have GUI apps that are front-ends to CLI apps is so that the code doesn't drift and you end up with a CLI version of an app that does things that the GUI version doesn't, and vice-versa. (Or even worse, one does it in a slightly different way than the other.)

Then it's better to follow what happens on Windows: usually an application shows a GUI when it's launched, but calling it with some parameter offers a command line interface.

This way the average Joe (which should be THE target of a system. Advanced users are already skilled enough to use it differently) is immediately satisfied, and you're giving an option to advanced users to use the application in their preferred style (CLI).

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.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Why was AmigaOS 4.X developed only for PowerPC?
Posted on 2-Sep-2018 6:47:26
#555 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@matthey

Quote:
matthey wrote:
Quote:
Hypex wrote:
x86/64 already has implicit and specific big endian support with the BSWAP and MOVEBE instructions so there is no excuse. Compilers are still playing catch up. AFAIK standard C/++ still does not support rotation even which has been in CPU instruction sets since time immemorial. So no surprises big endian data types are still not supported.

MOVBE is 2 bytes longer than MOV (minimum of 4 bytes but more if a 64 bit operation or using r8-r15). CISC should be able to do an operation at the same time.

Let's look at a simple case of adding a 32 bit number in memory to a number in a register.

risc_noswap:
lw r0,(r2) ; 4 bytes
add r0,r0,r1 ; 4 bytes
total: 2 instructions, 8 bytes of code, 3 registers used

cisc_noswap:
add.l (a0),d0 ; 2 bytes
total: 1 instruction, 2 bytes of code, 2 registers used

cisc_movbe:
movbe (r2),r0 ; 4 bytes
add r1,r0 ; 2 bytes
total: 2 instructions, 6 bytes of code, 3 registers used

cisc_bswap:
mov (r2),r0 ; 2 bytes
bswap r0 ; 3 bytes
add r1,r0 ; 2 bytes
total: 3 instructions, 7 bytes of code, 3 registers used

Now incrementing a variable in memory by one.

risc_noswap:
lw r0,(r2) ; 4 bytes
add r0,r0,1 ; 4 bytes
stw r0,(r2) ; 4 bytes
total: 3 instructions, 12 bytes of code, 2 registers used

cisc_noswap:
addq.l #1,(a0) ; 2 bytes
total: 1 instruction, 2 bytes of code, 1 register used

cisc_movbe:
movbe (r2),r0 ; 4 bytes
add $1,r0 ; 3 bytes
movbe r0,(r2) ; 4 bytes
total: 3 instructions, 11 bytes of code, 2 registers used

cisc_bswap:
mov (r2),r0 ; 2 bytes
bswap r0 ; 3 bytes
add $1,r0 ; 3 bytes
bswap r0 ; 3 bytes
mov r0,(r2) ; 2 bytes
total: 5 instructions, 13 bytes of code, 2 registers used

Using MOVBE may not be too much worse than inefficient RISC but the advantages of CISC are lost (reduced instruction count, better code density, smaller instructions, fewer registers used and reduced memory traffic).

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.
Quote:
Endian swapping all the time is a big penalty on the x86_64 (porting a whole AmigaOS but using all big endian data for compatibility) even though most modern x86_64 CPUs are probably going to outperform any available PPC CPU while doing it.

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.
Quote:
Quote:
There is the extended memory feature.

The PPC equivalent of PAE/LPAE? Sure. I have heard 64 bit PPC code is much bigger and slower so this probably helps with that. I wonder how well it works with the AmigaOS 4 gfx drivers using high end gfx cards needing lots of address space?

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.
Quote:
2) Shared memory can be accessed by any task which is a security risk.

This is the tricky part. It is possible to have messages, message ports and even libraries in supervisor memory which are not visible to everyone but resources in supervisor memory can't safely access user level resources and user level resources must trap/switch to supervisor mode to use supervisor resources. There is a hard wall/barrier between user and supervisor mode. The AmigaOS primarily uses user mode which is performance efficient but is almost like not having a supervisor mode at all. I don't think this security problem can be solved without custom hardware including a custom MMU. I propose a superuser mode (user->superuser->supervisor->hypervisor) with a MMU setting in page tables. Superuser marked memory would trap to supervisor mode if accessed in user mode but not in superuser mode. All MMU tables could only be changed in supervisor mode. All memory and resources which can do something dangerous would be allocated with superuser marked memory. A switch to supervisor mode would be required to check for authorization (perhaps a password) but then programs could operate in user/superuser mode most of the time without the overhead of switching to supervisor mode. Most programs wouldn't be aware of whether they are in user or superuser mode although a quick user level check of a flag could avoid some traps to supervisor for security aware programs. This would effectively add a fast and compatible supervisor mode to the Amiga without much of the overhead of switching to supervisor. I believe it would require minimal changes to current MMU designs and would be compatible with other operating systems. This would be a good idea to run past ThoR if the Amiga situation was not such a mess.

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..
Quote:
Quote:
Jason McMullan summoned up the AmigaOS efficiencies pretty well in an interview.
[quote]
Some of the AmigaOS advantages I like are things like:

o No system call overhead.
o Message passing by reference (instead of copying the entire message packet via a pipe or FIFO).
o User-level interrupt handlers.

But these advantages are solely possible by the biggest disadvantage of AmigaOS and AmigaOS derived operating systems - minimal to nonexistent memory protection, and a single-CPU architecture. Pavel Fedin is working on better MMU and SMP support for AROS, and I wish him the best of luck. The underlying AmigaOS architecture make this a very interesting problem.

Not to mention learning m68k assembly, which I had not been exposed to before last fall (2010).

Also, I would like to say that MorphOS and AmigaOS could benefit from opening up their source code - people such as myself are often looking for an interesting challenge to their programming skills, and releasing some of their kernel and library sources could help develop more interest (and ports to other hardware!) of their systems.


That is coming from a POSIX/Unix guy! I left in the last part because hiding away the AmigaOS and only targeting a niche market is killing the Amiga. Jason's talent should never have been allowed to walk away from the Amiga but this is typical of the kind of talent that has become discouraged and left. Can we retain the Amiga philosophy and leverage the Amiga's advantages with creativity or do we emulate inefficient operating systems? Full creativity and good compatibility requires custom hardware and we need it to be mass produced and affordable!

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

 Status: Offline
Profile     Report this post  
bison 
Re: Why was AmigaOS 4.X developed only for PowerPC?
Posted on 2-Sep-2018 13:12:39
#556 ]
Elite Member
Joined: 18-Dec-2007
Posts: 2112
From: N-Space

@cdimauro

Quote:
Then why not running Windows application, as I stated before?

That would involve bringing Wine into the picture, which I suppose is OK, but I'd rather run native apps. Chromium on Linux is better than Chromium on Wine on Linux.

Quote:
Then it's better to follow what happens on Windows: usually an application shows a GUI when it's launched, but calling it with some parameter offers a command line interface.

That would work, I like the other way round better, since few people start GUI apps from the command line.

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

 Status: Offline
Profile     Report this post  
Karlos 
Re: Why was AmigaOS 4.X developed only for PowerPC?
Posted on 2-Sep-2018 13:15:13
#557 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

I think the real question here is why was Amiga OS4 not ported to 6502? Just think of the untapped 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 2-Sep-2018 13:19:10
#558 ]
Elite Member
Joined: 25-Mar-2005
Posts: 11540
From: In the village

@Karlos

Quote:
=I think the real question here is why was Amiga OS4 not ported to 6502? Just think of the untapped potential.


That's more like where Amiga started, as opposed to where it might be going.
...Jay.....Atari....6502.

#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 2-Sep-2018 14:39:09
#559 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@bison

Quote:

bison wrote:
@cdimauro

Quote:
Then why not running Windows application, as I stated before?

That would involve bringing Wine into the picture, which I suppose is OK,

Don't know how much, since Wine is written for Linux and it's (almost) POSIX APIs.
Quote:
but I'd rather run native apps. Chromium on Linux is better than Chromium on Wine on Linux.

Like WinUAE on Windows which is better than WinUAE on Wine on Linux.
Quote:
Quote:
Then it's better to follow what happens on Windows: usually an application shows a GUI when it's launched, but calling it with some parameter offers a command line interface.

That would work, I like the other way round better, since few people start GUI apps from the command line.

Well, I think that the point is that normally people starts (GUI) applications from the GUI. This is the default for the average Joe.

Running GUI applications from command-line is also possible, but that's something which advanced users do.

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.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Why was AmigaOS 4.X developed only for PowerPC?
Posted on 2-Sep-2018 14:40:30
#560 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3621
From: Germany

@Karlos

Quote:

Karlos wrote:
I think the real question here is why was Amiga OS4 not ported to 6502? Just think of the untapped potential.

OS4 already uses bank switching for memory exactly like the good old 6502s with their advanced memory expansions, so... why not?

 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 Next Page )

[ 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