@pavlor

Quote:

pavlor wrote: I don´t think so. If it looks like AmigaOS, runs Amiga applications like AmigaOS and has general "feeling" of AmigaOS, then it is AmigaOS by my definition.

The problem is running the Amiga applications, and for a new o.s. this is achievable only using an emulator (or a sort of "virtualizer" which allows to run them as regular Windows apps. That's what I briefly described in my previous comment).

But it's something that you don't like and that's why you're waiting a Tabor board/machine, right?
Quote:

You know, I never played your game. Users don´t care about "things under the hood", they want to run their software in familiar enviroment. You may call this cheating, for me it is sensible progress.

As a developer I can understand what customers need, albeit it's quite difficult many times, because usually customers don't know what they REALLY want (and you are an evident example here ).

Anyway, and to answer to your real question (finally), yes, this is achievable, as I described before. So, you have 2 options here:
- create a bounty to improve QEMU in order to had a video card emulation which allows to use composition, and to add FPU support to the JIT. That's if you like the emulation way;
- create a bounty for a "virtualizer", like the VAMOS project, to enable full Amiga o.s. applications execution.

But pay attention: neither of the two will introduce modern o.s. features. It's only the host o.s. which is protected, as usual, but NOT the Amiga applications. This is not possible, as I've already explained.

Satisfied?

@cdimauro

It's not a problem to spin up multiple emulation instances to run multiple amiga applications, that's what many of us do already. The only drawback is that these applications cannot speak with one-another over arexx, but that is something that for most cases actually can be solved :)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla: I know it very well.

However my "virtualizer" idea allows to run either Amiga o.s. applications as separate processes (so, fully isolated from all other applications. And no message passing, of course), or as threads in a single process (so, like the Amiga o.s.).

@cdimauro

Quote:

If you have complex structures ("objects") then a dynamic list is a better general, and future-proof, mechanism.

It is. I've formulated an API function in my mind for past ideas and it gets complicated if you try to stick multiple parameters and split it up between similar functions or trying to use a general structure for one size fits all. In that case a dynamic list is a good idea. Old and depreciated parameters can be left behind.

However, the OS4 bros has stated that this is also limited, since the OS API is 32-bit and doesn't directly support 64-bit pointers or data.

Quote:

Another alternative is having a fixed structure (and/or a set of fixed parameters), and then getters and setters for extra parameters/attributes.

Yes and this sounds like OOP. Where the object is hidden. This is also how datatypes work, with a private object, and attributes set or got, with the methods. But, the implementation in AmigaOS, is a mess. They've tried to stick a C++ idea in a C only OS and it shows. Even include files with macros would have helped to keep it clean. But they've taken the idea to OS4 with C structures used to point to custom API function pointers. So it's neater but they didn't fix up datatypes which would have worked better with the "methodical" system they put in place.

It's a bit like sticking lipstick on a pig. You can't make a silk purse from a sow's ear.

The AmigaOS API is stuck on C. It really needs to be C++. Or Objective C. Or some similar OOP C. If they stick to C. However I propose AmigaE would be a better substitute. You can freely mix procedural and OOP code in one source, Works like magic. It puts the "MUI Mess" to shame which is an OOP design. But, like AmigaOS4 API and datatypes, an OOP design hacked into an old non-OOP C language.

Quote:

The 80286 had a 16-bit ALU, but 32-bit pointers for the largest memory model (with 1GB of virtual address space, and 24 bit of physical memory addressable).

So the 80286 was almost, but not quite, there yet, with no cache. Similar to the 68010, that had poor mans cache loop mode. I find the 80286 also presents an interesting time in Amiga history. I met this woman once who had an 80286 PC. At a time when it was becoming obsolete. But, one thing I saw that may seem trivial, is that Windows had context menus. AmigaOS didn't, and in that century, it was never properly added to the OS or Workbench. She pointed this out, which for her made the difference for usability. I guess she would have hated a Mac, which didn't even have a right mouse button. After using one, it sorely needed it.

Quote:

The 80386 had 32-bit and 48-bit respectively, but the most common memory model was a flatten, 4GB, one.

And cache. Finally a match for the 68020 released a year earlier. Didn't take long.

Quote:

Hum. Questionable. The 80386 did so well (even without the BSWAP instruction) that Intel decided to "kill" the agreements/contracts with third-party vendors like AMD (used to be second suppliers for IBM, for example), which then had to reverse engineer and recreate from scratch the missing microcode (Intel gave them up to the 80286 one).

The 80386 was extended better. They used the base registers and expanded the width. Then added more. Of course they also did so by adding letters to mnemonics which just made a mess of it. I think it would have been better to adopt the Motorola convention of .B, .W and .L what ever is going on under the hood. Easier to understand than AL, AX or EAX. At least to me, since variable widths were part of the 68K, not added onto like x86, so it looks confusing to me. Being able to isolate upper 8-bit byte from AH looks useful. If the R in RAX of 64-bit really means Really then AMD were being silly.

By comparison the 65816 was extended to 16-bits in the obvious way but also in a slightly crippled way. Since the accumulator, X and Y register were extended to double width but not much more apart from 24-bit addressing.

Quote:

Regarding the comparison with Motorola, the main problem is that the 68000 successors came always late compared to the "equivalent" Intel product. And starting from the 80486, Intel released versions with much higher clocks, which compensated and outperformed the Motorola processors at the end.

Looks like they had it up to the 68020. At least technically. But you can only get so far by starting ahead until you stall in the race.

Quote:

I think that it's a fake. I don't give a penny to this theory.

It's hard to find information on. The closest I can find is this reference form John Sculley. But it is later than I am talking about.

https://www.cultofmac.com/63295/john-sculley-on-steve-jobs-the-full-interview-transcript/

Quote:

I think that this is related to the code which was developed by Hyperion contractors. Hyperion has only PowerPC licenses about that work.

Which included the Frieden bro coders. Contracted out to work on OS4. Thus, their reason why there wouldn't be an x86 port. I do recall the early OS4 mini shell, which IIRC, was also running on x86 as proof of concept. But that info is hard to find on the net.

Quote:

But AFAIR the agreement between Amiga Inc and Hyperion is not restricted to PowerPC, and Hyperion should have the right to use the Amiga o.s. 3.1 sources for whatever they want to do, included porting to x86 or x64. But in this case either they have to license the new code from its contractors (due to the above PowerPC license) or completely rewrite it.

Well this goes back years since this was before there were disputes. Just years after the PPC port. Amiga Inc, headed by Bill McEwen, were certainly pro x86. But had no interest in AmigaOS. Or Amiga hardware at that point. Thus things like AmigaDE, running on x86, cashing in on the Amiga name.

Quote:

I never tried Amibridge/Janus, so I cannot answer here.

I tried it with icAROS also, where most components were included, and the bridge was still broken.

Quote:

The processor is very similar, so you should know its very complex instructions.

I made up a table once and penned it down with red and blue ink. So very complex on a 6502 core isn't very complex in general. I even worked on a 6502 emulator in C once. It was mostly working. Aside from clock cycles.

Quote:

I'm atheist. About everything.

I'm doubting your belief in atheism.

Would you believe in AtheOS?

I think having a rational to doubt is better than assuming something is true because of the populace or because it cannot be proven but is morel likely to be true. Statistics are irrelevant when it comes to being fact or fiction, a thing is either fact or fiction, and not because of stats I think. To me, if one claimed to be truly rational, then "I don't know" or "We don't know" is a more rational and proper answer to things we truly don't know and are beyond our reach. But for some that answer isn't good enough because it doesn't provide an answer. Not every question for a yes or no answer gets a yes or no but some other response. Perhaps I am touching on quantum states here, but yes or no can only be answered if the answer is known, if unknown it cannot. Yes, no, known, unknown. and now I wonder what I'm saying. Do I know what i'm on about? What ever.

Quote:

AROS is 68K binary compatible, and you can have also an AROS' Kickstart ROM (albeit it takes more than 512KB).

It must have taken some effort. Could this be a future OS for the Vampire?

Quote:

BTW, AROS is not an Amiga o.s. clone. The goal is to have (at least) v3.1 compatibility, but new things were also introduced.

Thus why I later said copy. I think they mainly reached their goal. But why set that as a goal? A road map? Reach that and go beyond?

Quote:

They are already different because OS4 diverged from the 3.1 roots. The same happens to MorphOS and AROS, but at the least they are more 3.1 compatible from a developer point-of-view.

It is different. Somewhat limited in 68K compatibility. MOS has a good model to separate 68K from native OS in filesystem. OS4 holds this too close. And it holds it back. You can't upgrade the OS with a new release. You must erase it and start again. The last month I've been migrating my XE files to my X1000. And I still haven't got it all working. The last thing I did was break the ENV system with Prefs complaining files were missing because something added to User-Startup that copied ENVs to RAM and messed it all up. I didn't spot it at first. Actually it was Wordworth. I copied it over and the fonts but they still didn't load even after running FixFonts and what not. Then ran the installer but it messed it up.

Quote:

Anyway, OS4 has no future. Its development is stalled from many years, and I hardly doubt that the "Duke Nukem Forever" version (AKA 4.2) will ever bring all promises that Hyperion made.

Still, development proceeds. Perhaps it is stalling because they are spending more time on supporting other machines and CPU differences than moving it forward. But these days people expect a browser to be included. Amiga had the desktop packs with office and games software. Perhaps AEON can fund and supply a decent browser in future.

Quote:

MorphOS seems to be still healthy. But I don't know how much they can continue sticking to the PowerPCs, which are dead (and not even from now).

All references I read on this subject say they will go AMD64. But we can also ask. Should MorphOS have been ported to x86 in the beginning?

Quote:

AROS lacks developers, but it's open sources and there is at least the chance that someone can take them and contribute. In fact, AROS-Exec is still active.

I still see it being developed. I think they should consider adding an Amithlon wrapper. Running native x86 Amithlon apps would be a killer. People go on about how fast Amithlon is on their modern PC and how it beats OS4 in 68K emulation. Well imagine that running on a native x86/x64 OS, it would beat the crap out of it. Of course, technically, Windows running on a fast PC easily beats any Amithlon emulator, so why bother and just run Windows? The programs would be faster then anything. They are native.

Quote:

It's not a browser problem, but an issue with the Amigaworld forum. Sometimes happens that if you click on the "quote" button (below the edit box), it didn't copy the text from the original message. And manually copying the smiles is a no-go for me...

I've seen that. But only on Odyssey. Seems fine with FireFox. Except the blank editing bug affecting all. But FF always annoys me by asking me to Allow for all I do on AW. Where is Allow All? I swear do we need an app for everything these days? For what used to be normal behaviour? It's damn user unfriendly at times. Can't search on here without it complaining about stale bread or something.

@Hypex

Quote:

The AmigaOS API is stuck on C. It really needs to be C++.

IMO absolutely *nothing* needs to be C++.

Especially in the maintenance phase of an application. Working on someone else's C++ code is even worse than working on someone else's Perl code.

Case in point: I refactored flwm a few years ago just to see if I could gain some knowledge of window managers by the exercise. It must have been written by two or more people who had different views on how the program should be structured, and there's a lot of hacking around things to make them work together. It's 4000 lines of insanity. I could write better abstractions in C.

Anyway, /* end rant */

---

Update: To be fair to the original author of flwm, I should add that I refactored the version used in Tiny Core Linux, which moves the window title bars from the left side of the window to the top. It could be that all the unstructured code I saw was a result of this change.

Last edited by bison on 07-Aug-2018 at 11:48 PM.
Last edited by bison on 07-Aug-2018 at 03:18 PM.

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

@cdimauro

Quote:

But it's something that you don't like and that's why you're waiting a Tabor board/machine, right?

If I don´t see any difference between AmigaOS4/PPC and AmigaOSNT/x64, then I have no need to dislike such solution. Until then, I´m waiting for Tabor (and using WinUAE).

Quote:

cdimauro wrote: You asked for "full OS4.x compatibility and all modern features" (your words) and this is simply IMPOSSIBLE. Because there are several TECHNICAL issues. Even if you try lo lower the bar with "(nearly) full compatibility" it's still NOT possible. The problem is the Amiga o.s. design itself, as I've already talked about. If you want modern features you need a NEW o.s. which works VERY DIFFERENTLY from the Amiga one. Hence: you lose backwards compatibility. That's something which an experienced Amiga developer knows, but if you don't trust me then you can ask some Amiga o.s. 3.1, OS4, MorphOS, AROS core developer. Some are users of this forum (or even on other forums).

I agree. Full AmigaOS compatibility is *not* possible with modern features but I wonder if some loss of compatibility and modern features is acceptable. AmigaOS 4 introduced memory protection over a decade ago but likely couldn't use it fully because of compatibility. Part of the problem may be wanting to turn features on completely (all or nothing). If AmigaOS allowed to turn certain security settings up, then new programs could be designed and tested using higher security settings and some people using only newer software would eventually be able to run in a more protected AmigaOS.

Security Prefs

Memory Protection
o none (best performance, no memory usage, best legacy compatibility)
o low (high performance, low memory usage, high legacy compatibility)
o medium (medium performance, medium memory usage, medium legacy compatibility)
o high (low performance, high memory usage, low legacy compatibility)

Resource Tracking
o off (no memory usage)
o on (low memory usage)

Multi-user
o off (no memory usage)
o on with low security (no inactivity logouts, GID ignored)
o on with medium security (inactivity logouts, GID)
o on with high security (inactivity logouts, GID, annoyances)

Supervisor/Interrupt Code
o allowed (best legacy compatibility)
o not allowed (reduced legacy compatibility)

This offers scale-ability from low end to high end systems, modularity and maximum compatibility. The Amiga may not be able to match the security features of other modern operating systems but I think it would have trouble competing in the high end anyway. Windows can't compete on the low to mid performance CPUs with the AmigaOS for performance and memory usage. All that security and abstraction gives a steep penalty to performance. I had a Pentium M Windows XP laptop with faulty fan dropping the clock to 800MHz and making it less responsive than my 68060 Amiga (the Pentium M is many times faster). Security is nice but how much performance and compatibility are users willing to trade?

Quote:

This is the first thing that OS4 and MorphOS will loose by moving to a little-endian ISA and/or a 64-bit one.

If moving to a 64 bit little endian ISA, it makes sense to break all compatibility and start over. This is what AROS x86_64 is doing although poor MMU support is holding up the memory protection. AROS does have SMP and partial resource tracking. I don't see AROS being successful for the x86_64 because of stiff OS competition which has more features and software. Gaining software support and developers is an uphill battle without selling mass produced hardware.

@bison

Quote:

IMO absolutely *nothing* needs to be C++.

LOL.

Quote:

Especially in the maintenance phase of an application. Working on someone else's C++ code is even worse than working on someone else's Perl code.

It's the in thing. AmigaOS is written in the in language of the day. Which is now C++.

However I gave a few other choices. My point was that even in '93 or so Commodore added things that needed an OOP language. Instead it was hacked into C which looked messy as well as not making sense when I read the autodocs (having no concept of OOP at the time). It was obvious they need to use a real OOP language for the job. The tradition of hacking OOP methods into a C interface continues today. They did a better job of it. But still failed to migrate the messy OOP functions over from datatypes or BOOPSI.

Quote:

Case in point: I refactored flwm a few years ago just to see if I could gain some knowledge of window managers by the exercise. It must have been written by two or more people who had different views on how the program should be structured, and there's a lot of hacking around things to make them work together. It's 4000 lines of insanity. I could write better abstractions in C.

4000 lines is insanity in itself.

Looking at datatypes as my prime example, there is NewDTObject(). I didn't understand the "New". Why was't it called AllocDTObject() I wondered. The "New" keyword tended be used to update older functions with a newer version.

Then we see things like DoDTMethod(). And if you go into that it gets messy from here on in. Earlier I didn't i understand why they made such a confusng and messy API. But after I understood OOP, thanks to AmigaE, I saw they were trying to do things like:

new DTObject;

DTObject->Method(Msg);

Anyway, /* end rant */

// Comment

@Hypex

Quote:

Which is now C++.

Not Rust? Swift? Go?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

How about a strict subset of C++, namely C with classes. A lot of the problems people have with C++ are due to the face there are so many ways to do something, you end up with code that's actually messy and less efficient and less portable than it should be. A problem compounded by obsolete implementations, etc. Just the other day, I was caught out by GCC6 not being able to link code in which a pure virtual class (interface) had a concrete implementation provided through a template, because the virtual table wasn't actually emitted. There was nothing wrong with the code per se, but the compiler implementation had issues.

By using only the fundamental features of the language you can achieve C's efficiency with improved type safety, usable abstractions and still have code that's easy to understand, extend and maintain.

Sometimes less is more.

_________________
Doing stupid things for fun...

@Hypex

Quote:

My point was that even in '93 or so Commodore added things that needed an OOP language.

Yeah, point taken.

I have a more general doubts about the underlying assumption of OPP, that computer programs ought to be structured like things in the real world. The Von Neumann architecture isn't very much like things in the real world.

Quote:

The tradition of hacking OOP methods into a C interface continues today.

I confess to being one of the perpetrators of such hacking. Polymorphism is especially hard to model. I use either function pointers or void pointers. Function pointers seems to be cleaner.

struct base {
	void (*print)(struct base *base);
	char *str;
};

struct more {
	void (*print)(struct more *more);
	char *str;
	int num;
};

static void print_base(struct base *ptr)
{
	puts(ptr->str);
}

static void print_more(struct more *ptr)
{
	printf("%s %d\n", ptr->str, ptr->num);
}

int main()
{
	struct base base = {print_base, "Hi"};
	base.print(&base);

	struct more more = {print_more, "Hello", 42};
	more.print(&more);
}

Last edited by bison on 08-Aug-2018 at 06:53 PM.

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

@Karlos

Quote:

Sometimes less is more.

Now you're singing my song.

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

@bison

Don't misunderstand me, I'm a huge C++ fanboy and for application programming it is a huge swiss army knife. However, for system programming you need to be selective about which language features you use.

_________________
Doing stupid things for fun...

@Hypex

Quote:

On a similar note, I once asked somebody, familar with Windows API, if there was an OpenWindow() or similar function for Windows. It's called Windows, of course there would. But I was told it didn't exactly. It has this MFC thing for a Microsoft Foundation Class and it derived from there. Now at this point I still had no idea of what OOP was. Only knowing about proecedual. So I didn't understand what this class thing was about. Nor how it worked without an OpenWindow() routine.

Your source wasn't familiar with the Windows API. The base win32 function is called "CreateWindow". One of the inputs is the class (window, button, listview, etc...).

https://msdn.microsoft.com/en-us/library/windows/desktop/ms632679(v=vs.85).aspx

All class libraries in the end call CreateWindow. MFC, .Net, Borland VCL, ...

Quote:

Hypex wrote: It's the in thing. AmigaOS is written in the in language of the day. Which is now C++.

I believe the most commonly used programming language today is Javascript. The language used to create executables for the largest number of CPUs is still C (C is the most common language for embedded use).

Quote:

However I gave a few other choices. My point was that even in '93 or so Commodore added things that needed an OOP language. Instead it was hacked into C which looked messy as well as not making sense when I read the autodocs (having no concept of OOP at the time). It was obvious they need to use a real OOP language for the job. The tradition of hacking OOP methods into a C interface continues today. They did a better job of it. But still failed to migrate the messy OOP functions over from datatypes or BOOPSI.

I don't understand how adding to a programming language designed to be extensible could be called "hacked". The AmigaOS BOOPSI and datatypes features and documentation could be more complete but I didn't think they were bad. There is some trade off between performance and resource sharing when OOP is used and I thought the AmigaOS did a good job of balancing them. The cost of indirect branches was much higher back then even on high end CPUs.

The cost of C++ on high end modern CPUs had decreased to low single digits until recently with Spectre side channel attacks. Intel's recommended Spectre security fix is quite costly.

Quote:

The second technique introduces the concept of a “return trampoline”, also known as “retpoline”. Essentially, software replaces indirect near jump and call instructions with a code sequence that includes pushing the target of the branch in question onto the stack and then executing a Return (RET) instruction to jump to that location, as Return instructions can generally be protected using this method. This technique may perform better than the first technique for certain workloads on many current Intel processors.

This effectively disables the indirect branch cache and link stack cache. If you were wondering what the first technique is, it is to upgrade your CPU or at least the microcode only possible on the newest CPUs. Universal code for affected CPUs will have to use the "return trampoline" technique to be safe. Funny thing is that the return trampolines will crash the Intel Control Flow Enforcement Technology shadow stacks which Intel was preparing to release for improved security (which have quite a performance cost as well). Spectre affects most OoO CPUs (although the x86_64 ISA is especially susceptible and weak on security) which will likely lead to less aggressive lower performance CPU designs and a higher performance cost for OOP code.

Quote:

Looking at datatypes as my prime example, there is NewDTObject(). I didn't understand the "New". Why was't it called AllocDTObject() I wondered. The "New" keyword tended be used to update older functions with a newer version.

Allocate is used to distribute existing resources but there are no existing DTObjects available. They must be created so CreateDTObject() or CreateDTObj() would have been better function names. I agree that the AmigaOS already uses "New" in upgrade functions making NewDTObject() a poor choice for a name.

Quote:

Quote: Anyway, /* end rant */ Or as I prefer, the easy way: // Comment

C++ style comments were allowed in C starting with C99. GCC's default sloppy C mode has allowed them for much longer.

@bison

Quote:

bison wrote: @Hypex Quote: The AmigaOS API is stuck on C. It really needs to be C++. IMO absolutely *nothing* needs to be C++. Especially in the maintenance phase of an application. Working on someone else's C++ code is even worse than working on someone else's Perl code.

It was bad enough when I had to work on C++ code that I wrote myself a year before...

After trying to follow all the delegations and creative inheriting for six levels I lost track of it... I could not wrap my head around it, and I wrote the thing myself and essentially knew the idea behind it!

Now I work with Haskell. It is also a complex language, but the maintenance phase is diametrical to C++.

@hth313

Quote:

Now I work with Haskell. It is also a complex language, but the maintenance phase is diametrical to C++.

I never made it up the learning curve on Haskell, so I'll have to take your word on that. I agree that the maintenance factor is important. I don't have any real preference between perl and python when writing new code, but if I have to work on someone else's code, I would much rather that it be python.

Last edited by bison on 10-Aug-2018 at 04:24 AM.

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

@Hypex
Quote:

Hypex wrote: @cdimauro However, the OS4 bros has stated that this is also limited, since the OS API is 32-bit and doesn't directly support 64-bit pointers or data.

It depends on the 64-bit ABI. The TagItem structure uses two ULONG fields, so if you define ULONG as a 64-bit integer type (like in all Unix-like o.ses), then the problem is solved.

The only problem that can happen is with code which assumes that ULONG is 32-bit / 4 bytes, without using operators like sizeof(). But that is a (very) badly written code.
Quote:

Yes and this sounds like OOP. Where the object is hidden. This is also how datatypes work, with a private object, and attributes set or got, with the methods. But, the implementation in AmigaOS, is a mess. They've tried to stick a C++ idea in a C only OS and it shows. Even include files with macros would have helped to keep it clean. But they've taken the idea to OS4 with C structures used to point to custom API function pointers. So it's neater but they didn't fix up datatypes which would have worked better with the "methodical" system they put in place. It's a bit like sticking lipstick on a pig. You can't make a silk purse from a sow's ear. The AmigaOS API is stuck on C. It really needs to be C++. Or Objective C. Or some similar OOP C. If they stick to C. However I propose AmigaE would be a better substitute. You can freely mix procedural and OOP code in one source, Works like magic. It puts the "MUI Mess" to shame which is an OOP design. But, like AmigaOS4 API and datatypes, an OOP design hacked into an old non-OOP C language.

No, please, do NOT try to force C++ to define o.s(es) APIs: it's too complex and messy.

(A subset of) C is small and clean enough for this purpose, and that's why it's used.

Unfortunately C isn't an OOP language, but defining methods as:

return_value class_plus_method_name(instance, ... parameters ...);

is acceptable in this context, without over-complicating what, remember, should be a general public interface for ALL languages.
Quote:

So the 80286 was almost, but not quite, there yet, with no cache. Similar to the 68010, that had poor mans cache loop mode.

80286 was quite fast.
Quote:

And cache. Finally a match for the 68020 released a year earlier. Didn't take long.

No really, because the 80386 had no cache, but burst mode (AFAIR). It performed very well even without any cache (some motherboards integrated an external one, but they were expensive, and not common).

That's strange, because the 68020 was introduced one year before, and it had code cache, so I was expecting the 80386 to have something similar.
Quote:

The 80386 was extended better. They used the base registers and expanded the width. Then added more. Of course they also did so by adding letters to mnemonics which just made a mess of it. I think it would have been better to adopt the Motorola convention of .B, .W and .L what ever is going on under the hood. Easier to understand than AL, AX or EAX. At least to me, since variable widths were part of the 68K, not added onto like x86, so it looks confusing to me.

Yup. 68K assembler is definitely much better from this PoV.
Quote:

Being able to isolate upper 8-bit byte from AH looks useful.

Personally I see it as awful. I would have preferred the possibility to access the 8-bit part of the other registers (SI, DI, SP, BP), in order to have an orthogonal ISA (and that's what the x64 did, finally).

The high registers are a dirty hack which is borrowed from Intel from a time when there was the need to have more 8-bit registers than 16-bit ones.
Quote:

If the R in RAX of 64-bit really means Really then AMD were being silly.

LOL
Quote:

By comparison the 65816 was extended to 16-bits in the obvious way but also in a slightly crippled way. Since the accumulator, X and Y register were extended to double width but not much more apart from 24-bit addressing.

The 65816 was an horrible patchwork. -_- Now that you broght it to my mind, I don't know which one is worse.
Quote:

Looks like they had it up to the 68020. At least technically. But you can only get so far by starting ahead until you stall in the race.

The 68020 was good, finally giving a full 32-bit ISA, but unfortunately introduced the double memory indirect addressing modes which crippled too much the micro-architecture improvement.

The 80386, which followed the next year, was a better performer, but it came later.

So here I see an advantage for Motorola; overall.

After that, Intel started to have advantage both introducing (first) its processors and reaching higher frequencies (and performances).
Quote:

It's hard to find information on. The closest I can find is this reference form John Sculley. But it is later than I am talking about. https://www.cultofmac.com/63295/john-sculley-on-steve-jobs-the-full-interview-transcript/

Hum. Here he was referring to the 1991 year (when the AIM consortium was created), so after the 80486 and 68040, when Motorola already shown to struggle reaching high frequencies for its processor, and Intel which was quite advanced in its 80586 (AKA Pentium) design. And Scully's talk made sense.

So, definitely NOT the 80286 and 80386 time which you reported previously about that argument.
Quote:

I made up a table once and penned it down with red and blue ink. So very complex on a 6502 core isn't very complex in general. I even worked on a 6502 emulator in C once. It was mostly working. Aside from clock cycles.

Same for me, but emulating a 65C02 (the processor used for a very well know Poker game in Italy: the so called "Pool X10" or something similar, which I don't remember exactly right now), and written in Turbo Pascal + inline 8086 machine language.

I've also created an high-level assembly language (and assembler), and an advanced & integrated debugger + resources. Quite a lot of work to reverse-engineer the board and the software.
Quote:

I'm doubting your belief in atheism. Would you believe in AtheOS?

Maybe I can create one.
Quote:

I think having a rational to doubt is better than assuming something is true because of the populace or because it cannot be proven but is morel likely to be true. Statistics are irrelevant when it comes to being fact or fiction, a thing is either fact or fiction, and not because of stats I think. To me, if one claimed to be truly rational, then "I don't know" or "We don't know" is a more rational and proper answer to things we truly don't know and are beyond our reach. But for some that answer isn't good enough because it doesn't provide an answer. Not every question for a yes or no answer gets a yes or no but some other response. Perhaps I am touching on quantum states here, but yes or no can only be answered if the answer is known, if unknown it cannot. Yes, no, known, unknown. and now I wonder what I'm saying. Do I know what i'm on about? What ever.

It's a too general and big topic. Let's say this: I've a rational and scientific mind, so I've a rigorous approach which, in the contexts which we were talking about, let me express opinions which may sound too much rigid and against fantasies and similar things.

But, in general, I'm not limited to: it should either false or true. "Don't know" is also a good option other kind of discussions/topics.
Quote:

It must have taken some effort. Could this be a future OS for the Vampire?

I think that AROS is the better candidate for Vampire. Vampire users are interested to 3.x Amiga o.s. version, albeit using their hardware platform, and 3.x isn't heavily developed right now (only some fixes and a few new features).
Quote:

Thus why I later said copy.

No, I don't think so: there are too many differences. It's not a 3.1 clone, but much more.
Quote:

I think they mainly reached their goal. But why set that as a goal? A road map? Reach that and go beyond?

The goals were already set from long time, albeit they are still not fully reached (but quite close for the 3.1 implementation).
Quote:

Still, development proceeds. Perhaps it is stalling because they are spending more time on supporting other machines and CPU differences than moving it forward.

I understand it, but anyway they cannot fulfill all promises that they made for 4.2.
Quote:

But these days people expect a browser to be included. Amiga had the desktop packs with office and games software. Perhaps AEON can fund and supply a decent browser in future.

Absolutely agree, but it might be expensive.
Quote:

All references I read on this subject say they will go AMD64. But we can also ask. Should MorphOS have been ported to x86 in the beginning?

No, PowerPC was good when they started to develop it.
Quote:

I still see it being developed. I think they should consider adding an Amithlon wrapper. Running native x86 Amithlon apps would be a killer. People go on about how fast Amithlon is on their modern PC and how it beats OS4 in 68K emulation. Well imagine that running on a native x86/x64 OS, it would beat the crap out of it. Of course, technically, Windows running on a fast PC easily beats any Amithlon emulator, so why bother and just run Windows? The programs would be faster then anything. They are native.

There was a project to better integrate the old 68K applications to AROS (for any hardware flavor), but now I don't recall the name.

Amithlon is completely different, but maybe something similar can be achieve using AROS as the host o.s., with the above project.

P.S. Sorry, again no time to review the writing and fixing typos.

@pavlor

Quote:

pavlor wrote: If I don´t see any difference between AmigaOS4/PPC and AmigaOSNT/x64, then I have no need to dislike such solution. Until then, I´m waiting for Tabor (and using WinUAE).

Actually it's only composition which is missing on WinUAE, right?

@cdimauro

Quote:

Actually it's only composition which is missing on WinUAE, right?

Sloooow network, sloooow disk I/O, slooooow FPU (well, Tabor is in the same boat...), slow GFX (2D), no 3D, no compositing, max RAM limitation (cca 640 MB is safe boundary, not much luck with more RAM).