AmigaOS filesystem layout

[matthey]

My emphasis. The same holds for AmigaOS (page 15 of the AmigaDOS manual). I think I've seen a few CD32 games that throw everything (startup-sequence and all) into the root directory.

Assign would have been more powerful if relative assignments could be reassigned when a parent assignment changes. If relative assigned were allowed, then all of these assigns:

Code: [Select]

Assign SYS: HD:
Assign C: SYS:C
Assign S: SYS:S
Assign L: SYS:L
Assign LIBS: SYS:Libs
Assign DEVS: SYS:Devs
Assign FONTS: SYS:Fonts
Assign LOCALE: SYS:Locale
Assign HELP: LOCALE:Help
Assign KEYMAPS: DEVS:Keymaps
Assign PRINTERS: DEVS:Printers
Assing ENVARC: SYS:Prefs/Env-Archive
Assign REXX: SYS:Rexx

could be reassigned to CD0: with:

Code: [Select]

Assign SYS: CD0: PATH

Even more powerful would be:

Code: [Select]

Assign SYS: CD0: PATH ADD

Note that this is not how assign currently works. Also, assign with PATH and ADD options won't work.

Both manuals go on to explain how to reassign the system to a hard drive, since bootable Amiga hard drives hadn't yet been invented at the time these were written. I imagine the precise order in which one reassigns the system shouldn't matter as long as it's the very first thing done.

I recall that the TripOS manual mentions a hard drive and using memory to copy C: commands to. I was surprised considering hard drives would have been rare and expensive and memory of most 68000 computers was probably 64k-128k at that time and also very expensive.

[matthey]

I wonder why that's DEVS: and not D:. I thought it had been added post-TripOS but obviously not.

I noticed that too. At least AmigaOS fixed the inconsistency by adding a new style "Libs" to go with the "Devs". Maybe they should have put the Classes in LIBS: though as the gadgets and datatypes are libraries. Then again, devices are libraries also, showing the Amiga was object oriented from very early. Building structures on structures like this is very efficient, Passing the structures as pointers in registers to function calls (without entering supervisor mode either) is still the most efficient way today. Tag lists which were introduced later are not as efficient. C is still the most efficient high level language too.

Agreed, that would be convenient. For the sake of argument, though, I'm wondering if there is a reason for why it's designed as it currently is, i.e., are there conditions under which one might want to reassign SYS: but keep C:, Libs:, Devs: etc. in their original places. Maybe it was just too complicated to implement at the time, since it would require the Assign command to recognize SYS: as a special entity.

I believe the current AmigaOS way of doing assign is the fastest and most memory efficient. It would be possible to store the original relative assign along with the optimized version which would be used most of the time for little extra memory cost today. More CPU processing would be required when an assign is changed as well. It may be possible to add relative functionality in a compatible way with a new assign command option.

The manual even says "If you are so lucky as to have a hard disk..."
But the memory thing surprised me too. I wonder what kind of machines Tripos was meant to run on? Did high-end 68000 workstations exist at universities or similar institutions? What other 68000 machines of that era could Tripos have targeted?

Yea, that's the quote I remembered but I was too lazy to go back and look it up for you.

The 68000 made a poor mans workstation. It lacked supervisor functionality common in workstations and servers but was otherwise similar to the VAX and PDP-11. The 68000 was more orthogonal with more registers than most cheaper <=16 bit processors, had 32 bit registers and wide operations from the beginning and didn't have to worry about memory banks or anything like that. This made it a better target for C compilers (and thus the AmigaOS) than most cheaper processors. The supervisor functionality was improved with the 68020 and then again with the addition of the MMU in the 68030. The 68020-68040 were popular in low end (affordable) workstations and servers. Then the RISC hype came along with Motorola's anti-68k marketing which killed the market even though the 68060 was a better CPU for the price (including how much memory was needed with it) than its replacements.

[matthey]

Which RISC are you talking about now? m88k?

No, PPC. Mororola threw away everything they failed to develop organically and decided what was on the other side of the fence was greener. The only organic ISA I recall them creating since adopting PPC is the MCore disaster of minimal ISA and hardware which was crushed by the much better ARM (ColdFire is a cut down 68k and removing isn't creating). Motorola had a loyal 68k customer base but they threw it away when they told everybody that RISC is the future. Now RISC PPC is practically dead after being destroyed by x86_64 CISC which is inferior to the 68k. Motorola is a Chinese company and Freescale will be Dutch. Game over.

[matthey]

Not quite sure what you mean. We have "symbolic" assignments that evaluate by "name" and not by "lock". That's precisely the "PATH" option.

I did some more tests with the PATH option of assign and you are correct. My AmigaDOS manual describes PATH as being useful for removable data (which it is) but fails to explain adequately what it is doing and what else it can be used for. The PATH option of assign keeps the relative path instead of converting it to an absolute path. If the original assigns for Libs:, Devs:, L: etc. were assigned with the PATH option and the S:Startup-Sequence changed to add PATH to the assigns:

Code: [Select]

Assign PRINTERS: DEVS:Printers PATH
Assign KEYAPS: DEVS:Keymaps PATH
Assign LOCALE: SYS:Locale PATH
Assign LIBS: SYS:Classes PATH ADD
Assign HELP: LOCALE:Help PATH
Assign REXX: SYS:Rexx PATH

then we could do:

Code: [Select]

Assign SYS: CD0:

One minor flaw of the assign PATH option is that it does not work well with ADD. For example:

Code: [Select]

Assign SYS: CD0: ADD

My tests would not locate data in the new PATHs (like "Assign LIBS: SYS:Libs PATH" which should look in CD0:Libs now also). Is this a bug or a limitation?

I don't think developing a CPU able to handle Big and Little Endian is  "throwing everything away." The rest of your conclusions are "an"  opinion.

Bi-endian CPUs are not a good idea, IMO. Instructions which handle endian conversion are a useful part of modern CPU support though. Any choice of CPU endianess is a minor issue and has little to do with anything I talked about. Some of my comments are opinionated. It's clear that Motorola made the wrong decisions but it is not clear what the right choices were. However, if Motorola could have seen the future of processors, they would have kept the 68k and devoted more resources and "positive" marketing to it. That's not to say that PPC was a bad choice at the time but they shouldn't have bet the farm on it. I went to an Amiga show in St. Louis during the '90s where they had a developer conference with several Motorola employes. They told us PPC was the future and hyped up how great it was. The 68k was already talked about as an old dead legacy processor but the 68060 was faster per clock, used 50% less memory and ran cooler than the "more advanced" PPC replacements. The 68060 was still for sale but Motorola was anti-marketing it. Some of my "opinions" are observations as I recall them from the time.

I'm not sure I'd call amd64 inferior to m68k, maybe in your nonexistant parallell universe where m68k was picked by IBM to power the first IBM PCs and m68k would enjoy the kind of attention that x86 has had. But in our universe, no.

How many processors or byte code ISAs since the x86 are based on an 8 bit variable length encoding? Java has an 8 bit byte code (it's so effiicent that most JAVA compilers don't even use it) and Java processors were created which have largely failed due to inefficiency. How many processors and byte code ISAs are based on a 16 bit variable length encoding like the 68k? ARM CPUs with Thumb 2 so the majority of processors produced. Dalvik byte code as used by Andoid is based on a 16 bit encoding. It is less known but used more than Java byte code. The 68k has a more efficient encoding, more powerful addressing modes, better code density and it's easier to read and program than x86 or x86_64. The 68k has not been developed in decades but this is actually easier (and with less baggage) to do now. The x86/x86_64 has excellent proven and well known CPU designs produced from huge amounts of cash flow while the 68k has not been developed and has no funding. The potential of the 68k is as good if not better though.

Well, SYS:Classes is multi-assigned to LIBS: so it is really.

True, It may be more efficient and user friendly to have shallow directory trees also. The datatypes drivers being in DEVS: might be more suspect of a decision as there are no devices related to datatypes.

[matthey]

Motorola did have a great CPU project in the works.  I helped work on it in Phoenix during my EMPLANT/FUSION haydays.  The CPU was basically a Xilinix on steroids.  We could load a CPU core into the chip.  There were 68000 and 80586 cores working, but not optimized.   It had the ability to byte/word/longword swap on the fly.  The project was scrapped, and the IBM partnership went forward making the PPC chips.

I'm not aware of what a Xilinix CPU is (surely not Xilinx FPGA technology). Do you have a reference or development project name to this Motorola CPU (or Xilinix CPU)? This project sounds like another EPIC (Explicit Parallel Instruction Computer) VLIW failure like the Itanium and Transmeta processors. VLIW is low power and can execute a lot of instructions in parallel when the code is predictable (some media data and DSP processing) but general purpose code is not and compilers can't solve this problem. It's very likely that billions of investment dollars have been wasted trying to make it work time and time again. Even if it's not VLIW, such CPU emulation with reduced hardware would need compiler and/or JIT support which can never be as efficient for general purpose code. Adding SIMD to a versatile integer CPU with efficient branch prediction is what has been successful.

They failed mostly due to lack of demand. Java just wasn't good enough for people to pay for a dedicated CPU.

The Java processors weren't used because they were slow so, yes, they failed because of lack of demand. There are some ARM processors which have hardware support (acceleration) for Java byte code which is much better than a Java byte code only CPU. There are applications for byte code like Java byte code but it will always be less efficient as it needs more processing than ready to run executables. Java byte code is not efficient or particularly well designed.

ARM becoming successful is purely down to their licensing terms and being in the right place at the right time.

The early ARM designs were transistor misers and became known for their power efficiency. ARM ISA designs have been innovative and well liked by developers. Yes, the licensing terms have been friendly also. ARM built a reputation by doing several things right. Does ARM have a big advantage in power efficiency of mid-performance processors compared to Atom (or a 68k could be)? I don't think so as ARM processors need transistor and energy expensive longer pipelines and OoO to compete in performance. There existing customers worried about power efficiency are still going to come back to them though. When performance is more important than power efficiency, they go to Intel. I don't think it would be difficult to produce a competive mid-range CPU but I expect it would be difficult to differentiate a new CPU and gain market share against this installed competition.