MATLAB

[fridtjof.ma...@gmail.com]

I am attempting putting MATLAB (1982 version) on the Altair-Duino.

Has anyone ever seen a CP/M-80 version of MATLAB?

Thanks
FredW

[fridtjof.ma...@gmail.com]

[Ross Presser]

On Sunday, April 10, 2022 at 5:07:31 PM UTC-4, fridtjof.ma...@gmail.com wrote:
> I am attempting putting MATLAB (1982 version) on the Altair-Duino.
>
> Has anyone ever seen a CP/M-80 version of MATLAB?

From the MATLAB history page, it does not appear that anything like MATLAB
existed before 1983 in any real form, and that the IBM PC's introduction was
the impetus to rewrite FORTRAN MATLAB in C, with the IBM PC as the first intended
target (and Unix workstations next).

[fridtjof.ma...@gmail.com]

I have the FORTRAN source for MATLAB 1982 and 1988. The main difference is that
SAVE statements were introduced into the 1988 version. That version has been run on VAX,
IBM-PC and some other platforms. The help file dates from 1981 (Cleve Moler).

I have built all FORTRAN code on Microsoft FORTRAN-80, and run through about 2000 lines.

I may be able to save space by reducing DOUBLE PRECISION to REAL, and am working on overlay structure for the code. I am using Phoenix PLINK-II to provides overlays.

Just a "for fun" project.

[Peter Ljungberg]

VAX, is that VMS?
Would be nice to have a copy of that ;-)
^P

[fridtjof.ma...@gmail.com]

Peter

Yes, VAX under VMS. 50,500 elements. I have it compiling and linking:

PSA Linkage Editor II (CP/M) [P20100-0114 ]
Copyright (C) 1981 by Phoenix Software Associates Ltd.

MATLAB.PRG (C988H, 51K)

: fred@fedora src $;

And, it does run, minimally....

: fred@fedora src $; execute matlab

Overlay loader Initialized
Request to load overlay 18: read from disk
Request to load overlay 76: read from disk
Calling 3440
Request to load overlay 11: read from disk
Calling 9990
Request to load overlay 49: read from disk
Request to load overlay 18: still in memory
FILES 1
Calling 9990
Request to load overlay 49: still in memory
FILES 1

< M A T L A B >
VERSION OF 05/25/82
Calling 9990
Request to load overlay 49: still in memory
FILES 9

HELP IS AVAILABLE
Calling 9990
Request to load overlay 62: read from disk
Request to load overlay 18: still in memory
Calling 9990
Request to load overlay 48: read from disk
Request to load overlay 18: still in memory
Calling 9990
Request to load overlay 48: still in memory
Calling 9990
Request to load overlay 48: still in memory
Calling 9990
Request to load overlay 48: still in memory
PARSE 0 0 0 0
Calling 9990
Request to load overlay 53: read from disk
Request to load overlay 18: still in memory

<>
Calling 3440
Request to load overlay 10: read from disk

I am further "squeezing" the code, and optimizing the overlay
structure. When I get this to the point of inputing,
inverting and printing a matrix, I will publish the project
to github.

Right now, code and buffer with only 15 elements takes 51k of memory.
We can go to 57k, giving 6k more memory for elements. At 8 bytes per
element, that gives us 783 elements total. I am looking to reduce the
code size by 10k, which would give us a maximum of 2048 elements. This
is less than the VAX/VMS 50500 elements and less than the usual 5005
elements.

On the publish to github, I will include 1982 and 1988 source for reference, along with
source that works on CP/M-80

FredW

[Rock Brentwood]

From fridtjof, Sunday, April 10, 2022:

In addition to the matlab80 project on GitHub for CP/M-80 (you?), matlab is included under /cmd/matlab in at least one distribution of version 10 UNIX that's still out there (on Paul McJones' historical archives page), and the Fortran sources are dated 1983. It has implementation of the system-dependent functions for CDC 6600, IBM CMS, DEC 10 & 20, PRIME 400, IBM TSO, VMS in system-dependent files (the CMS has machine-language code in it, too), as well as a generic UNIX implementation of the functions. It is mostly Fortran. There is a VAX file and a few C files and headers. Most (or, now: all?) the system dependencies pertain to things that are now in the standard libraries for Fortran (or C). It has a script file to turn double precision into single precision, and to turn that 50005 magic number into 5005. The routines FILES, SAVLOD, FORMZ, FLOP, XCHAR, USER, PROMPT, PLOT, EDIT and MAIN are system-dependent; most are now handled by standard library functions; others (like PLOT, PROMPT, USER) now abstract out and generalize to interface-dependent modules (i.e. to different terminal and GUI interfaces).

There are 3 file name changes ({comand,factor,round}m.f versus {comand,factor,round}.f), the CP/M 80 version segregated initializations to init.f and declarations to {common,funcs,matlab}.h, while the UNIX version has the low-level files for {ofault,onbrk,setjmp,sgset} - used in the driver routine, and helper (for the help function). The CP/M 80 version balked on any the driver routine and just runs the MATLAB function. The CP/M 80 version avoids the duplicating of single and double precision, which the UNIX version does, by using conditional definitions in an include file.

They should have waited a few years before doing the translation, and they jumped the gun a bit, since they would have eventually seen that translation to C++ would be better because (1) the large number of reference parameters in the Fortran functions, (2) matrix operations can be more transparently rendered with operator[] and even operator(), (3) equivalences can be better-handled with reference types, (4) the common blocks can be more directly rendered as namespaces, (5) templates to directly translate both single and double precision into a single code base, and (6) the complex arithmetic might be better-handled by the compiler and standard library functions, if the code is put back into complex form ... the same applies to the Fortran version, as well, and even the Fortran source should be lifted back to complex. There's a large amount of code bloating that occurred because of the decimation of complex to component reals (not just variables and parameters, but even whole routines, got real-imaginary part split).

At some point, maybe recently, MathWorks lifted the user interface part of their version of the code to Qt ... which works best with C++.

[Rock Brentwood]

On Saturday, June 11, 2022 at 3:08:48 PM UTC-5, Rock Brentwood wrote:
> From fridtjof, Sunday, April 10, 2022:
> > I am attempting putting MATLAB (1982 version) on the Altair-Duino.
> > Has anyone ever seen a CP/M-80 version of MATLAB?

> In addition to the matlab80 project on GitHub for CP/M-80 (you?), matlab is included under /cmd/matlab in at least one distribution of version 10 UNIX that's still out there (on Paul McJones' historical archives page), and the Fortran sources are dated 1983.

Some additional notes: the MATLAB projected started off as a small project by a professor over in New Mexico, Cleve Moler. His name is in several places under the larger functions in the Fortran source. It was actually his students who took it and ran with it. Both he and others involved in the projects are with MathWorks -- even now at the time of writing. This is note from 2018 on the history of MATLAB from Moler, himself:

https://blogs.mathworks.com/cleve/2018/02/05/the-historic-matlab-users-guide/

and it lists 1981 as the beginning.

He's still around - his most recent blog is from yesterday. He worked with EISPACK and LINPACK, which also has close entanglements with LAPACK, though he does not seem to have any connection with that. LAPACK is back in full maintenance on GitHub. MATLAB is essentially a front end for the older Fortran packages (which is also why it has that klunky 1960's look and feel.)

Given what he said in the historical note, if this were to be done today, it would actually be done simply as an extensible C++ source-code library, since part of the aim was to have code-extensibility - so that means you want a source code library. I highly suspect that this may have led another package: ALGLIB. It has routines for matrix operations, FFT, neural net routines, optimization, differentiation, integration and other code, but is compiled in as source code (in any of several languages), not as a library. But it has no run-time front-end.

[Rock Brentwood]

On Saturday, June 11, 2022 at 3:08:48 PM UTC-5, Rock Brentwood wrote:

> They should have waited a few years before doing the translation, and they jumped the gun a bit, since they would have eventually seen that translation to C++ would be better because

[reasons (1) to (6)]

... but - as another note - one of the main reasons for translation to C++ instead of to C is that (7) the Fortran source is seriously mucked up with all sorts of calls to a routine "FLOP" threaded everywhere in it; and this reduced the transparency and simplicity of the code to the limit of easy maintainability into virtually becoming legacy-code. By the documentation's own admission FLOP is really just a sloppy FLOP counter - in part because of its haphazard threading throughout the code. What the author is really trying to do is put up a continuous monitor on all the floating point operations.

This is best done, either outside the application, in a current thread, or by appropriating and encapsulating all the floating point routines in a class that does the relevant operator counts. The latter cases makes it possible to do more comprehensive stats, while at the same time removing all the threading from the source - if it's done in C++. I don't know if the Fortran source, itself, can be lifted to a class-based version (what's needed are classes and user-definable arithmetic operators, in Fortran, like C++'s "operator+()"). But, it can't be done in C.