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?
Thanks
FredW
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++.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)