|
---|
| | Geoff Wells
Posts 43 02 Jul 2019 16:13
| Hi @Gunnar I would not call you old fashioned at all. I have a huge respect for the entire team. The level of dedication and commitment is incredible. Thank you very much for all the hard work! I agree that there is still lots of work to be done to reach 100% compatibility and so this may not be a priority. It is, however, a thorny problem that can benefit from some discussion and planning. Perhaps I am being too optimistic but I'm wondering what's next after reaching 100%. We may even find, through discussion, that there is something simple that could be done which gets new people interested in helping out. The thing with a problem like this is the inter-dependency. I think a discussion today on approach may not yield implemented improvements for a while but if there was interest in an augmented hardware approach it would change the dialogue. If there is no interest then we would be left with only a software approach which clearly suffers from all of the problems that have been identified. Knowing that there was something that could solve the problem in hardware would result in a dependency for the improvements that may be years away but would be a road map item of interest.
| |
| | Mr Niding
Posts 459 02 Jul 2019 16:34
| As a non-developer I read this forum, and I do notice that people usually talk in non-spesifics, as to what tasks and functionality they would like to see. Real spesifics.
| |
| | Geoff Wells
Posts 43 02 Jul 2019 16:59
| @Mr Niding Is your comment in reference to a specific post? I am certainly happy to get into more detail but I'm not sure the benefit if the topic isn't of interest. The OP seemed to be trying to understand the future of the Amiga platform and put forward improving stability as something that should be considered. It seemed to me like an interesting area of discussion but I can also appreciate that it may be more work it's worth if there's no real future in the platform. In terms of specifics, I have a background in Electrical Engineering and software development. I coded for many years in C/C++ but not ASM nor do I have a background in developing for FPGAs (I've done a some reading and understand the principles). It is clear there are many people on this forum with outstanding knowledge and skill. I guess I'm hoping to have a more detailed conversation on the MPU with the goal of understanding the options for enabling page management in support of improving AROS stability. If that should be in a separate thread or not the way things are done here then no problem. If it is more appropriate that I go away and figure something out and put forward a proposal I could do that as well but I guess I'd like to first at least know if it is a non-starter.
| |
| | Nsklaus -
Posts 63 02 Jul 2019 17:53
| @gunnar doing things in correct order is good. it is just brainstorming. at least from my part that's what is was. 1) aros succeeding at being a viable aos clone/alternative in the traditional, original sense. 2) what next ? how things could get improved ? doesn't hurt to discuss this. it's not because noone found a solution yet that this topic should be off-limits. beside, having separate code branch is always possible, so there's no messing around. aros-classic branch (aim at being as closest possible to original aos) aros-experimental branch (aim at improving the limitations) @Wells thinking out of the box is good, if a hardware solution can help, or just about anything else at all then why not ? any ideas, any attempt should be welcomed. as gunnar said ealier in this topic, people have tried to think about a solution for this for 30 years. so i guess that means there is interest for it. i personnaly think they all failed because they wanted to add the new feature without modifying the existing. or another possibility could be because they wanted to do it "by the book" implementing memory protection as it is meant to be, as it is defined. but in reality, anything that could improve the situation would be good to have. being some sort of hybrid half mp, being software or hardware, being something completely different, it's all good as long as the result is significantly improved stability.
| |
| | Nsklaus -
Posts 63 02 Jul 2019 18:06
| in video game development, when you want to move your character, you register the input, you check first where the new position would be, then, - if it is ok, you allow it and make the move - if it is bad you revert back to old position maybe the same could be done with memory writes. i guess i will be answered to would be to costly to check all memory writes before performing them ?then maybe the os need a transparent "middle man" taking care of memory allocations, like with the load balancer analogy, all memory writes should be sent to him and he decide where it's good to write. in the load balancer case, response time is important too, linux kernel dispatch requests very quickly to available cloned servers.
| |
| | Geoff Wells
Posts 43 02 Jul 2019 18:30
| @Nsklaus Thanks for the feedback. I'm actually of the opinion that backwards compatibility is critically important. There are many examples of hardware platforms that fail due to lack of market or software support so servicing the retro market for this platform is very important as the basis for continued work. I do agree that it is worth taking another look at. I personally would be willing to give up some performance for stability but only if it was relatively small since part of the elegance of AOS is it's light-weight and high performance profiles. I also think many smart people have already looked into a purely software solution which is why the change of approach is required to make progress. @Gunner Is there any value in a new mode for the MPU to help with this? I'm asking this without an understanding of the current structures in your MPU. Could the MPU have a mode where the writable pages are defined in a page table by process but the entire memory space is accessible/readable. This would allow processes to read anything but only write to areas that are allocated to the process as managed by the OS. This would only help if processes only read data defined by other processes and didn't update it. If that is not the case I humbly withdraw my suggestion.
| |
| | Nsklaus -
Posts 63 02 Jul 2019 19:01
| @wells i'm not against backward compatibility in itself, as long as it doesn't prevent having a stable, functionnal base. amiga always did shine with its multitasking, the ability to run more than one task at the same time. it can run them alright, but it cannot properly stop them. i remember i was shocked when i discovered this. the resources are never freed, and killing a crashed task is a high risk endangering the whole system. this is not serious. this is unfinished business. if commodore hadn't died the aos team would of course have found a remedy to that state of thing in the following updates, which never came because well commodore died and work stopped. why people think 3.1api is final is un-understandable to me. they have to realize we would have had updates over time and things would have changed little by little. about performance impact, amiga has a lot of room for this, loosing a bit of perfs still won't make it slower than other OSes. on the 'change of approach' side of the argument, i can only praise.
| |
| | Nsklaus -
Posts 63 02 Jul 2019 19:22
| otoh, about your argument for importance of backward compatibility: "There are many examples of hardware platforms that fail due to lack of market or software support so servicing the retro market for this platform is very important as the basis for continued work." yes well amiga, as a platform, has already failed. even with all its software base being available. might as well trying something new it can't hurt anymore the amiga than it already is. the only users still there, are the ones who knew amiga and used it back in the days. amiga is not gaining new users but rather loosing them a bit more each new year passing by. the situation is a bit bad i'd say. breaking compatibility intentionaly in order to improve things, that one haven't been tried yet. after 30years of keeping backward compatibility mantra, seeing that didn't do much to help in the end, might as well try something different here too. and "retro market for this platform" won't magically refuse to run original aos3.1 on real amiga or on uae, and all software base won't magicaly refuse to run anymore on original aos3.1. at worst we could get an optional experimental build that noone will like or use. but i fail to see how it could erase original aos3.1 from the past ? running original with all its software base will always be what it is. noone can undo the past. what is already there is here to stay.
| |
| | Gunnar von Boehn (Apollo Team Member) Posts 6258 02 Jul 2019 19:39
| Geoff Wells wrote:
| Is there any value in a new mode for the MPU to help with this?
|
Let me try to answer this. I think this is a question of OS concept. On Unix a program is not allowed to access anything. A program can not read any hardware. It always need to ask the OS to do this job for it. On AMIGA this is very very different. Each program can read everything. This makes programming on AMIGA so "fast" and "vivid" this is why coding on AMIGA feels much better. Your program wants to know if MOUSE BUTTON is pressed? Only 1 ASM instruction BTST is needed for this. On Unix this is different. Your program needs to switch context to the OS. The OS needs do this check and needs to provide the info to the program. Some things which need 1 instruction on AMIGA need 100 or 1000 Instructions on Unix. This is why AMIGA OS is so much faster. On AMIGA OS if 2 programs "talk to each other" they exchange PTRs and each program knows about the other. And to send a message the program just pokes to value into the other program. This is how AMIGA works. Direct, easy simple. On Unix this is done completely differently. No program can send data to another - this simple as on AMIGA. I think AMIGA by design makes inter program communication super easy. Programs have no borders, no limits. Each program can simply query the fire button with a single instruction. To "invent memory protection" you need to kill this. You need literally to break _every_ existing Amiga program. And literally need to code like on Linux. If you did this - the result would not AMIGA OS anymore. It would be Linux with MagicWb Icons.
| |
| | Mr Niding
Posts 459 02 Jul 2019 19:44
| @Geoff Wells It was more a general comment, and I see the team being somewhat neutral/shrugish in response after 100s of suggestions with no actual task/puropse in mind. Im sure you and Steve Ferrels got alot to talk about since hes a seasoned C++ man, but also isnt ASM oriented, which is why the brainstorming related to GCC and Stefan is promising. Oh, and welcome by the way! Always nice to see active developers here :)
| |
| | Nsklaus -
Posts 63 02 Jul 2019 19:52
| @gunnarprototype you maybe lack imagination. do you really think commodore engineers would have been happy with aos3.1 for ever ? of course not. amiga developpers are just affraid to think what commodore enginners would have done next for the OS. i remember haynie even had an experimental prototype cpu card with two 68k on it. i remember there was talks about memory protection for future updates. it never came only because commodore died.
| |
| | Gunnar von Boehn (Apollo Team Member) Posts 6258 02 Jul 2019 19:58
| nsklaus - wrote:
| @gunnar you maybe lack imagination. |
Maybe I do. But I know what I know - I know the AMIGA OS functions and libraries. - I know the AMIGA OS sources. - I understand the idea and concept of AMIGA OS And I know Linux very well. Based on this I can explain the difference in philosophy. AMIGA OS has a philosophy which contradicts Linux and Memory Protection. Educate yourself about AMIGA design.
| |
| | Nsklaus -
Posts 63 02 Jul 2019 20:03
| @gunnar educate yourself on logic. aos3.1 was not meant to be the last amigaOS version. memory protection was planned and so was smp. if logic only doesn't tell you this, i suggest you dig old interviews you can see picture of the dualcpu prototypes, and hear the original team talk about memory protection and what was planned next.
| |
| | Philippe Flype (Apollo Team Member) Posts 299 02 Jul 2019 20:27
| I agree that AmigaOS would have evolved in a manner that even it would not have continued on Motorola technology (depending on many factors). Currentely we still use Motorola tech, improving it (in a reasonible scale, since FPGA are not offering infinite room for all the ideas we would like implement). Current state does not allow to modify the AmigaOS3.X in a manner that SMP could be implemented, so well, we can discuss hours, it is normal, the topic is passionnating, but current arch still offers a large spectrum to have many funs with it.
| |
| | Nsklaus -
Posts 63 02 Jul 2019 20:29
| am i a troll now? really ? EXTERNAL LINK you can see in the article they weren't affraid of experimenting. memory trickery, mmu used, custom exec.. etc imagine commodore didn't die, if they had time to continue working on amigaos and amiga hardware. new chipset were planned, lots of different prototype being worked on, it was alive. it was evolving, it was being maintained, updated, The Big Plan was not to end with amigaos 3.1. they just got interrupted by commodore demise. you can call me a troll for stating the obvious that doesn't change anything. in this article he is not saying: "oh no i wouldn't dare make a modification, 3.1 api is so perfect, we won't change anything"the amiga design you know so well was not meant to be the end of it. there was updates planned. that is my whole point.
| |
| | Gunnar von Boehn (Apollo Team Member) Posts 6258 02 Jul 2019 21:08
| nsklaus - wrote:
| am i a troll now? really ? |
My personal impression is that many experienced amiga coder love AMIGA OS for what it is. They love AMIGA OS for its freedom and its elegance. I sometimes see people which have very little experience in coding on AMIGA - and they regard this AMIGA Freedom as weakness and they want to sacrifice it on the alter of Linux and memory protection. I'm not sure how to call this. I believe that these people have good intentions ... Maybe a good match is "Luke 23:34"
| |
| | Steve Ferrell
Posts 424 02 Jul 2019 21:11
| nsklaus - wrote:
| am i a troll now? really ? |
Yes, I would agree that you are a troll. It's been explained to you by several people here why AmigaOS cannot be updated with memory protection or other modern features without sacrificing backward compatibility. Even when the reasons why such a task cannot be accomplished are explained to you, you then stoop to insulting people...i.e. telling Gunnar he needs to learn logic! Do you realize how much logic is required to bring a dead CPU architecture up to modern 64-bit standards and enhance it with SIMD capabilities? Obviously not, or you wouldn't have made such an absurd statement. Again, you'd be better off taking some time to educate yourself about basic operating system design and memory protection rather than antagonizing folks here who are much more logical and better educated than you. Here's a place for a good start, and to make things simpler, on the first page, simply replace all entries for MS-DOS with AmigaDOS or AmigaOS: EXTERNAL LINK
| |
| | Geoff Wells
Posts 43 02 Jul 2019 21:27
| @Gunnar Thanks. I do understand the difference in implementation between Unix and AmigaOS. Back in the day I did X Windows development and even a bit of kernel hacking in FreeBSD. I'm over 20 years out of date but still understand the high level concepts. I don't want to make AOS/AROS like Unix and I'm not too interested in a hosted environment (ARIX/UAE/ABox/etc.). My joy, as I'm sure with many here, is the elegance of the 68K based hardware combined with the original OS. I just have a feeling we could do more with the OS in a complimentary way similar to what you've achieved with AMMX. The context switch to the kernel in Unix is what allows for memory protection along with the hardware abstraction layer. I'm not interested in that overhead. However, some of the examples you sight could still be done with read-only context (mouse position, fire button, etc.). Blitting to screen memory would be a write but also into an area of memory that could be public and less risky. Perhaps I could start a separate thread to gather all of the standard mechanisms that require direct memory access and try to build a suggestion for providing a good approach. The worst that could happen is that I confirm and document for everyone's benefit that it is not possible. :) @Mr Niding Thanks for the follow up. Wasn't sure if I needed to add more. And thanks for the welcome. @nsklaus Thanks for the feedback. I think perhaps your passion is coming through a little strong. I don't think Gunner is lacking in imagination but perhaps has different priorities. He's seen the problem many times - as we all know this is not a new idea - and wants to make sure we keep true to the Amiga philosophy. I say thanks for keeping us honest! Hopefully, our different opinions can make the ultimate solution better.
| |
| | Nsklaus -
Posts 63 02 Jul 2019 21:31
| alright, this discussion ends here for me. i've said enough. please continue and enjoy yourselves.
| |
| | Renee Cousins (Apollo Team Member) Posts 142 02 Jul 2019 22:05
| nsklaus - wrote:
| memory protection was planned and so was smp. |
If we're being really honest with ourselves, we know this to be false. The next step was Hombre and PA-RISC running Windows NT. Amiga OS would become the CD64 OS (to keep costs down) and otherwise exist only as OS-friendly emulation.
| |
|