@kolla

Quote:

Please explain to me why such a license would exist? Amiga had ARexx by William S. Hawes, NOT IBM's REXX interpreter. And the look of OS/2 does not resemble anything Amiga at all. And which came first - OS/2 or ARexx?

OS/2 1.x Presentation Manager GUI has Microsoft's Windows 2.x look.
https://en.wikipedia.org/wiki/Presentation_Manager#/media/File:Os2-1.1-desktop.png

After IBM and MS separated, IBM created its 32-bit OS/2 2.0.

https://www.os2museum.com/wp/os2-history/os2-2-0/os2ga_desk/
OS/2 2.0 GA Desktop. Notice the window's top buttons and desktop icons on the left-hand side.

Microsoft has a 32-bit OS/2 3.0 project (renamed into Windows NT) since 1988.

Last edited by Hammer on 21-Dec-2024 at 12:05 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

Yes... and?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Karlos

Quote:

Karlos wrote: I always wanted to create a version of ARexx that had strong scalar type support and basic vectors and maps, while retaining the free form stem aggregate structures. It would be nice if also compiles down to a more machine interpretable intermediate form for execution too.

Could you give me a use case for expanding ARexx in such a way?

_________________
All the way, with 68k

@agami

It would be fun.

ARexx was the defacto scripting language for AmigaOS and application interoperability. The only issues I ever really had with it were the fact it was so slow. You could write some cool operation and bind it to your paint program but it might be too slow to be practical.

Part of that is due to the fact it's an interpreted language, but on top of that, it's an old school method of interpretation. The code is parsed line by line every time it runs. It's much more commonplace now for interpreted languages to be parsed to some dorm of machine interpreter bytecode prior to execution.

Adding strong scalar type support and arrays/maps is developer fetishism but both help when it comes to writing code that would be more performant in execution.

You could never go completely type safe since you'd lose a key feature which is the stem variable concept and you'd also have the issue that various functions may return different types. So you're always going to need a "any" type.

Last edited by Karlos on 21-Dec-2024 at 09:26 AM.

_________________
Doing stupid things for fun...

@kolla

IBM is just covering itself.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Karlos

Quote:

Karlos wrote: @agami It would be fun. ARexx was the defacto scripting language for AmigaOS and application interoperability. The only issues I ever really had with it were the fact it was so slow. You could write some cool operation and bind it to your paint program but it might be too slow to be practical.

Sounds like you were trying to use it for more than just scripting.

On my A1200 with 50MHz 030 AREXX does ~3500 empty do loops per second, 4,000 'integer' additions and 2300 floating point additions. Amiga BASIC would be faster if it ran at all, but it doesn't so...

Quote:

Adding strong scalar type support and arrays/maps is developer fetishism but both help when it comes to writing code that would be more performant in execution.

Yes. I don't know even know what half those things are!

@Karlos

PC's decision-making document automation with MS Office and 3rd party software (e.g. accounting, document management, database, search engine, custom business process), its VBA, and COM interface via Visual C++ (from 1993)/Builder C++ (from 1997) or Delphi (from 1995).

PC's decision-making document automation with MS Office is the "killer app" in PC's 1990s and into 2000s.


-------------------------------
The US and EU are investigating MS Office 365's dominance(1).

1. https://www.ciodive.com/news/microsoft-eu-antitrust-software-bundling-teams-office/719845/

Google Cloud filed a complaint with the U.S. Federal Trade Commission accusing Microsoft of anticompetitive business practices in cloud one year ago. The FTC initiated a cloud market investigation in March 2023 that remains ongoing.

The European Commission inquiry has no official deadline. The length of EU antitrust cases depends on case complexity and the degree of cooperation by the party under investigation, the Commission said. Microsoft has been granted the opportunity to submit a written reply and request an oral hearing.

Some old story in the 21st century.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@bhabbott

Quote:

However IBM did have a reason to 'cross license' other Amiga IP, particularly patents. You never know when some obscure patent might come in handy, as we found out with the infamous XOR troll. According to Dave Haynie "We knew they wanted a license on the Amiga patents to keep them out of trouble if we came after a patent on them... It was just one of those general 'cover your ass and get some money out of everyone else in the business' deals". OS/2 was designed to be a protected-mode successor of PC DOS for the 286. IBM intended to use it in their PS/2 computers, released in 1987. Its system calls were modeled after DOS and it had a text-based interface. Later on it got a GUI courtesy of Microsoft, similar to the GUI they used in Windows 1.0 in 1985.

OS/2 1.1 with Presentation Manager GUI was released in 1988. OS/2 1.1's GUI look-and-feel is based on Windows 2.x GUI.
https://en.wikipedia.org/wiki/Presentation_Manager#/media/File:Os2-1.1-desktop.png

OS/2 1.1 with Presentation Manager GUI is not based on 1985 Windows 1.0's tiled window GUI.

PS; My Dad's work issued him an IBM PS/2 Model 55SX PC with an unused OS/2 1.x copy and Windows 3.0 on it. IBM PS/2 Model 55SX PC was later decommissioned, it was later traded for 386DX-33/ET4000-based PC clone build.

IBM PS/2 Model 55SX PC has 387 FPU in the socket.

From 1985 to 1990, IBM dictated OS/2 1.x to be designed around 286's protected mode while Bill Gates wanted 386.

From 1985, Compaq, Intel, and Microsoft worked on Compaq 386 and Windows 2.x 386. Meanwhile, Microsoft used privileged access with IBM to create a VGA and 8514 drivers for Windows 2.x.

Windows 2.x supports 256-color desktop.

Last edited by Hammer on 22-Dec-2024 at 02:18 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

None the wiser - what does Presentation Manager GUI have to do with Amiga?
What does IBM have to do with ARexx?

Why would IBM license "look and feel" of OS 2.x from CBM for a product they had already shipped (Presentation Manager GUI) and for which there's no resemblance with OS 2.x? The "myth" says OS/2 and not Presentation Manager, but OS/2 also doesn't look at all like Amiga.

And why would CBM license REXX from IBM when they already had acquired ARexx?

Last edited by kolla on 23-Dec-2024 at 11:10 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@bhabbott

Quote:

bhabbott wrote: @Karlos Sounds like you were trying to use it for more than just scripting.

And? Does a scripting language have to be slow? Who says a scripting language can't be used for whatever you can think of?

Here's a popular scripting language doing something more fun: https://youtu.be/qr4CvcSNHtM?si=S-qy8-KP483GLmrQ

Quote:

On my A1200 with 50MHz 030 AREXX does ~3500 empty do loops per second, 4,000 'integer' additions and 2300 floating point additions. Amiga BASIC would be faster if it ran at all, but it doesn't so...

So you agree, performance is disappointing. A use case in point, OctaMED has great ARexx support but the performance of the language is too slow to make the most use of it, particularly the sample editor. There was a patch that allows native code plugins via the arexx interface, which was both good and bad. Good that you could use it, but bad in that it served to underscore the limitations imposed by the performance of the arexx interpreter.

Quote:

Quote: Adding strong scalar type support and arrays/maps is developer fetishism but both help when it comes to writing code that would be more performant in execution. Yes. I don't know even know what half those things are!

I'm pretty sure you know what a scalar type is (int, bool, float, for the purposes of ARexx, string) and what an array is. A map is an array that maps an input to an output, rather than a straight linear array (aka vector).

-edit-
Swypos. Like typos, but from using a stupid touch screen.

Last edited by Karlos on 23-Dec-2024 at 11:47 AM.
Last edited by Karlos on 23-Dec-2024 at 11:45 AM.
Last edited by Karlos on 23-Dec-2024 at 11:38 AM.
Last edited by Karlos on 23-Dec-2024 at 11:37 AM.

_________________
Doing stupid things for fun...

@kolla

Quote:

kolla wrote: None the wiser - what does Presentation Manager GUI have to do with Amiga? What does IBM have to do with ARexx? Why would IBM license "look and feel" of OS 2.x from CBM for a product they had already shipped (Presentation Manager GUI)

Presentation Manager GUI is Microsoft's IP since IBM's OS/2 1.0 GUI was late.

In 1989, OS/2 1.2 had the 1st 3D beveled GUI design for Presentation Manager.

https://arstechnica.com/information-technology/2019/11/half-an-operating-system-the-triumph-and-tragedy-of-os2/

IBM still saw Microsoft as a partner in the operating systems business, and it offered to help the smaller company by doing a full promotional rollout of Windows 3.0. But in exchange, IBM wanted to buy out the rights to the software itself, nullifying the DOS agreement that let Microsoft license to third parties. Bill Gates looked at this and thought about it carefully—and he decided to walk away from the deal.

IBM saw this as a betrayal and circulated internal memos that the company would no longer be writing any third-party applications for Windows. The separation was about to get nasty.

Unfortunately, Microsoft still had contractual obligations for developing OS/2. IBM, in a fit of pique, decided that it no longer needed the software company’s help. In an apt twist given the operating system’s name, the two companies decided to split OS/2 down the middle. At the time, this parting of the ways was compared to a divorce.

IBM would take over the development of OS/2 1.x, including the upcoming 1.3 release that was intended to lower RAM requirements. It would also take over the work that had already been done on OS/2 2.0, which was the long-awaited 32-bit rewrite. By this time, IBM finally bowed to the inevitable and admitted its flagship OS really needed to be detached from the 286 chip.


IBM's R&D progress is slow. IBM deserves to be kicked out of the PC standards.

https://www.landley.net/history/mirror/os2/history/os220/os2la_desk.gif
OS/2 2.0's initial desktop icons on the bottom

https://www.landley.net/history/mirror/os2/history/os220/os2ga_desk.gif
OS/2 2.0 GA (General Availability)'s initial desktop icons are mostly on the left like Amiga Workbench 2.0.

https://youtu.be/-DAojx2Hgec?t=2468
OS/2 2.1's two-button mouse function demo.

MacOS's initial desktop icons are on the right-hand side.

Windows 95's initial desktop icons are on the left-hand side.

Windows NT 3.1 was chasing after SGI on memory-protected, multi-user, and multi-CPU support.

68K platforms would have a higher chance when IBM stayed with the "brain bead" 16bit 286, but there's Compaq 386 (part of the gang of nine), Xenix 386, Windows 386 (with Excel GUI/WinWord), and price-reducing with continual performance improving SVGA clones.

PS/2 product range uncompetitive price vs performance relative to 68K platforms.


Quote:

and for which there's no resemblance with OS 2.x? The "myth" says OS/2 and not Presentation Manager, but OS/2 also doesn't look at all like Amiga.

It's just legal coverage.

https://www.landley.net/history/mirror/os2/history/os220/workframe.gif
For OS2 2.x, IBM WorkFrame with full gray 3D GUI. OS/2 2.x top window buttons are closer to Workbench 2.0's.

License swaps don't limit creativity for the companies involved.

Last edited by Hammer on 24-Dec-2024 at 02:45 AM.
Last edited by Hammer on 23-Dec-2024 at 11:04 PM.
Last edited by Hammer on 23-Dec-2024 at 11:01 PM.
Last edited by Hammer on 23-Dec-2024 at 10:57 PM.
Last edited by Hammer on 23-Dec-2024 at 10:40 PM.
Last edited by Hammer on 23-Dec-2024 at 10:36 PM.
Last edited by Hammer on 23-Dec-2024 at 10:35 PM.
Last edited by Hammer on 23-Dec-2024 at 10:30 PM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Karlos

Quote:

Karlos wrote: @bhabbott So you agree, performance is disappointing.

Disappointing means "failing to meet the expectation or hope of". I wasn't expecting an interpreted scripting language to be a speed demon.

So what was disappointing? AmigaDOS scripting. I tested an empty 'for next' loop implementation and it only managed a miserable 16.4 iterations per second. ARexx was 210 times faster.

I also tried Amiga Python 2.0. It was 3.6 times faster ARexx, but had a huge footprint. The interpreter alone is 774k (compare that to 32k for rexsyslib and 968 bytes for the rx command).

Quote:

A use case in point, OctaMED has great ARexx support but the performance of the language is too slow to make the most use of it, particularly the sample editor.

OctaMED's sample editing functions are quite basic and shouldn't require much to control them. What were you using ARexx for, processing sound samples?

Quote:

There was a patch that allows native code plugins via the arexx interface, which was both good and bad. Good that you could use it, but bad in that it served to underscore the limitations imposed by the performance of the arexx interpreter.

IMO the most important part of ARexx is the interface to applications with ARexx ports. You don't actually need ARexx itself to make use of them, but since it's there...

ARexx certainly could control 'plugins' that perform various operations on samples, which should have minimal overhead. This is how I would expect it to be used for CPU intensive operations. I don't see why a patch would be needed unless OctaMED's ARexx interface was somehow inadequate.

@bhabbott

Note that hope and expectation are different. You don't expect a scripting language to be fast but you might still hope to be wrong about it.

The ARexx port in OctaMED was advanced enough that you could perform sample editing, that's the point. The patch I described allowed native code to take over that job because writing, for example, a 4 pole multimodal filter in ARexx, although entirely possible, was completely impractical.

For a while I was pretty proficient in writing ARexx code and coupled with AWNPipe in OS3.5 and above made a number of utilities with GUI. They all worked (well, until anything resulted in a read/write issue in the pipe) but as you can imagine they weren't the fastest.

As I said, the thought of writing an improved execution environment for the language is just a fun self-nerdsnipe.

A distant ancestor of MC64K was a bytecode machine I wrote back when I primarily used my BlizzPPC/040. An unoptimised version (basic C implementation) could clock around 2-3 MIPS on the 040 and 50-20 on the 603. An optimised version (proper jump table, threaded dispatch) could probably run twice as fast.

It doesn't take much to imagine a simple ARexx parser that translates all the source to bytecode for execution. This doesn't have to be via any temporary files, just a cache in memory and some mechanisms to understand if the cache has been invalidated. Or maybe you just don't bother and just allow the cache to be enabled, purged and disabled at will. Disable during development of a script, enable the rest of the time.

Even without a cache and a worst case assumption that your parser is slower than the original, you would benefit the first time you hit a loop and don't have to repeatedly parse the statements on each iteration.

The interesting challenges are things like efficiently keeping track of all the values, ad-hoc data structures (stems) etc.

Last edited by Karlos on 24-Dec-2024 at 09:19 AM.
Last edited by Karlos on 24-Dec-2024 at 09:09 AM.
Last edited by Karlos on 24-Dec-2024 at 08:58 AM.

_________________
Doing stupid things for fun...

Also, don't forget the most important thing. By adding some notion of enforceable scalar data types, I get to call it TRexx.

Totally worth it, just for that

I am, of course, grossly oversimplifying what would be necessary to compile down what is a rather high level language that has lots of runtime evaluation of strings.

Last edited by Karlos on 24-Dec-2024 at 07:19 PM.

_________________
Doing stupid things for fun...

Karlos Quote:

Also, don't forget the most important thing. By adding some notion of enforceable scalar data types, I get to call it TRexx. Totally worth it, just for that I am, of course, grossly oversimplifying what would be necessary to compile down what is a rather high level language that has lots of runtime evaluation of strings.

I wanted optional C style datatype support for ARexx before you suggested it. The "TRexx" name is clever for a multi-platform Rexx too.

@matthey

Well, I have only just suggested it, but I have thought it for years. I just never did anything about it.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @bhabbott The ARexx port in OctaMED was advanced enough that you could perform sample editing, that's the point. The patch I described allowed native code to take over that job because writing, for example, a 4 pole multimodal filter in ARexx, although entirely possible, was completely impractical.

There's hope, and then there's pie in the sky wishful thinking. I might hope that ARexx was about as fast as other interpreted scripting languages, but not much more than that. It's certainly way faster than the previous offering (and much easier to use). Sure it was slow when doing CPU intensive tasks like 4th order filtering of sound samples, but no reasonable person would expect otherwise.

Quote:

For a while I was pretty proficient in writing ARexx code and coupled with AWNPipe in OS3.5 and above made a number of utilities with GUI. They all worked (well, until anything resulted in a read/write issue in the pipe) but as you can imagine they weren't the fastest.

I imagine that sucking samples out of OctaMED through the ARexx port one byte at a time and pushing them back again wouldn't be fast either. Not sure why you would need a pipe for this but then AWNPipe has GUI creation features too which I suppose might be useful - though with somewhat onerous dependencies.

Quote:

As I said, the thought of writing an improved execution environment for the language is just a fun self-nerdsnipe.

Ah, I get it now.

This reminds me of when I bought a ZX Spectrum for the purpose of sucking the tape routines out of the ROM to make my ZX81 load programs faster. Of course that didn't happen, as I quickly realized that the Spectrum made the ZX81 itself redundant. Many years later a guy by the name of Francisco developed OTLA, which increased loading speed from 300 bps to between 7350 and 16200 bps, up to 54 times faster! Amazing how much improvement can be achieved on these old machines just by using more efficient code.

The ZX81 had a very bad tape interface that involved recording a series of pulses followed by a gap, 4 pulses for a 0 and 9 for a 1. As well as being slow, this format is very bad for tape because it isn't symmetrical so the waveform gets distorted as it goes through the audio interface, making loading unreliable. The ZX81's tape interface was developed from an addon for the MK14, which used a gated oscillator to produce pulses in hardware. Whoever designed this circuit obviously had no clue about how to design a cassette tape interface. Yet despite this poor design the ZX81 was a hit, selling over 1.5 million units globally.

A few years later Commodore produced the C64 which was the biggest selling home computer of all time (over 12 million units sold globally) with a seriously flawed disk drive interface that once again suffered from legacy baggage. More proof that a design didn't have to be the best to be popular.

But these design flaws are actually good for the hobby because they make it more interesting. The joy of getting your ZX81 or C64 to load programs many times faster is well worth it. Modern PCs are dead boring because they are incredibly powerful and everything just works, and if it doesn't there's not much a mere mortal can do about it because they are so complex. You didn't have to be a genius to figure out how to improve a ZX81. The Amiga was a bit more complex but still possible to enhance with simple circuits and/or a bit of asm code, not difficult for those of us who had cut our teeth on simpler 8-bit machines.

Developing a bytecode translater for ARexx is beyond my skills, but probably not difficult for someone 'experienced in the art'. If I was doing it I wouldn't worry about sticking too strictly to the REXX spec. Your idea of enforceable scalar data types is a good one.

Last edited by bhabbott on 25-Dec-2024 at 03:51 AM.

@bhabbott

Quote:

Developing a bytecode translater for ARexx is beyond my skills, but probably not difficult for someone 'experienced in the art'. If I was doing it I wouldn't worry about sticking too strictly to the REXX spec. Your idea of enforceable scalar data types is a good one.

The script to bytecode translator (parser, lexer etc), and keeping track of the state efficiently are challenge areas I think. Devising a sensible bytecode and interpreter for it are usually fairly straightforward. Not too dissimilar to writing an emulator except it's usually a lot simpler since you're not trying to emulate specific side effects (status reg) of individual instructions.

There needs to be some syntactic sugar for specifying datatypes where they are used/passed/returned. It's always adding syntax where confusing new parsing ambiguities are born.

Ideally I'd like to keep the datatypes simple and not necessarily machine oriented, e.g. bool, int, float, string (not really a scalar but we can make it have by value semantics). But maybe there's some sense in it being more specific, eg int32, float32 etc.

Arrays and maps would be the icing on the cake. With stems you can create linked lists and all sorts, but basic arrays was always a PITA. Maps are ideal for creating associative data. They'd all need sensible syntax as well.

Last edited by Karlos on 25-Dec-2024 at 11:53 AM.

_________________
Doing stupid things for fun...

@Karlos

Isn’t lack of typing considered one of the defining core features of Rexx?
Anyways, Regina is there for anyone who may wish to experiment :)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

I don't know that I'd call it a feature so much as a pitfall. Don't get me wrong, dynamic typing has many uses and especially simplifies things like serialisation and deserialisation in many languages.

The motivation for adding type support goes hand in hand with lower level execution. Once you've removed parsing overhead of a source level interpreter, you very quickly begin to reach additional bottlenecks around runtime type manipulation and interconversion.

At a higher level, it gives you the ability to write better-defined code. At least in theory, anyway.

In theory theory is like practise. In practise, it isn't.

_________________
Doing stupid things for fun...