Can we learn from Amiga OS?

[bwinkel67]

Of course, if we are talking about the history of the Amiga we have to remember that the first (pre-release) version of AmigaDOS was written in BCPL by Metacommco (I believe on QLs).

Do you have a reference for that. I see that Metacommco started in 1981 and the base for AmigaOS was TRIPOS which ran on a PDP-11. The timeline would seem odd since the QL didn't really start shipping until summer of 1984 (first customers got buggy versions in April/May) and the AmigaOS came out a year later in summer of 1985. Metacommco ported software to the QL (I have the BCPL compiler).

[stephen_usher]

I don't have the info at hand I'm afraid, I read it years (decades?) ago.

AmigaDOS was indeed a re-implementation of TripOS, which was developed in Cambridge and written in BCPL. As I understand it Commodore and Metacommco didn't have the rights to the original implementation and so copied it functionally. It was re-written again in C before release anyway.

In about 1990 I helped a local financial adviser who had an m68k based TripOS machine and used my knowledge of AmigaDOS to fix the machine a couple of times.

[bwinkel67]

I think most C compilers can integrate assembly. To Peter's point, it's hard to maintain an assembly code base. Back in the mid 90's I worked for BBN in their speech group and they had a large speech system written in C mostly by electrical engineers (i.e. the code weren't pretty) but they used every technique imaginable to squeeze speed out of the system (no array subscripting allowed). Before that, in the early 90's I needed to use my QL for work and wrote a terminal emulator in Digital 'C' and it was loosing characters so I had to get creative. One trick was to get rid of double jumps which I knew were happening since I assumed the compiler was likely not optimizing. So changing code from this:

Code: Select all

   for (;;)
   {
      switch (ch)
      {
         case 10:
            /* code goes here */
            break;
         case 13:
            /* code goes here */
            break;
         default:
      }
   }

To get rid of the break jumping to the end of the loop to then have it jump to the top of it I changed it to this:

Code: Select all

   loop:
   {
      switch (ch)
      {
         case 10:
            /* code goes here */
            goto loop;
         case 13:
            /* code goes here */
            goto loop;
         default:
      }
   }

Before this my terminal program sometimes dropped a character and after this it stopped losing any. So you can tighten code if you have an idea how a compiler generates its output.

Secondly, with high level languages you have the opportunity to think more flexibly of implementing different algorithms to solve the same problem in my opinion. I just improved my ZXSimulator three-fold by moving from pixel plotting the character drawing. It only added about 2K to the code base though I may reduce its size by removing redundancies.

That said, there are occasions where you have may need to integrate assembly. I may want to eventually modify the QL font set for the ZXSimulator to get optimal speed (I still have about 40% to go) and not sure if I can fully set that up within C though that would be preferable (Digital 'C' lets you link in assembly code).

[tofro]

Secondly, with high level languages you have the opportunity to think more flexibly of implementing different algorithms to solve the same problem in my opinion. I just improved my ZXSimulator three-fold by moving from pixel plotting the character drawing. It only added about 2K to the code base though I may reduce its size by removing redundancies.

Well, what you did there was actually using assembly-written code instead of C - The character plotting routine in QDOS does, in the end, only plot pixels as well - but in machine code. I guess that proves a point.

Tobias

[NormanDunbar]

Hi Tobias,

The character plotting routine in QDOS does, in the end, only plot pixels as well - but in machine code. I guess that proves a point.

Does it? I have a funny feeling - possibly from something of Simon N Goodwin's - that it doesn't actually PLOT the pixels, more writes the scan line data into the 9 rows that the character takes up on the screen? With adjustments for CSIZE and INK, PAPER and/or STRIP colours of course.

Obviously, I could be wrong .....
Again!


Cheers,
Norm.

[pjw]

Parts of this discussion remind me of an interview I once heard on the BBC radio. It was with some renowned French philosopher. Among much else he said: "The beauty of the French language is that exactly expresses what you think." At that point I switched channel..

[bwinkel67]

Well, what you did there was actually using assembly-written code instead of C - The character plotting routine in QDOS does, in the end, only plot pixels as well - but in machine code. I guess that proves a point.

Yes you are going to use an API and apply built-in routines within source code. But how that API manifests itself in a program helps manage the code base. The end-argument is, how easy can you understand, modify, augment code and the point of a high-level language is that it captures those ideas better. Also, in the end, the compiled code ends up being machine code with the difference in how it was generated (by machine vs by hand) and this discussion is about whether one can generate it efficiently using a compiler (i.e. by machine).

[tofro]

Hi Tobias,

The character plotting routine in QDOS does, in the end, only plot pixels as well - but in machine code. I guess that proves a point.

Does it? I have a funny feeling - possibly from something of Simon N Goodwin's - that it doesn't actually PLOT the pixels, more writes the scan line data into the 9 rows that the character takes up on the screen? With adjustments for CSIZE and INK, PAPER and/or STRIP colours of course.

Obviously, I could be wrong .....
Again!


Cheers,
Norm.

Norman,
that's more or less what SpeedScreen does - It checks whether character positions align with font origins and handles this special case much faster than original QDOS. Well, in the end, QDOS doesn't literally call the PLOT routine, of course.

Tobias

[NormanDunbar]

Thanks Tobias.

Cheers,
Norm.

[janbredenbeek]

that's more or less what SpeedScreen does - It checks whether character positions align with font origins and handles this special case much faster than original QDOS. Well, in the end, QDOS doesn't literally call the PLOT routine, of course.

Not only the character positions, also the various colour and OVER combinations. It's fastest when you write white on black (and with CSIZE 1,0 since that uses 8-pixel wide characters). I've always found it a pity that the QL lacked a character-mapped display mode like the BBC's teletext mode.
Apart from that, I/O will be much faster when handling multiple bytes at once in one TRAP (IO.FSTRG/IO.SSTRG) since you don't have the overhead of switching contexts with each character. I had to devise my own string-based queue handling in QLTERM to make it as efficient as possible, which was also needed given the poor state of the serial ports at that time...

Jan