Chuck, your post just reminded me of how I used
FORTRAN to interface with my PDP-11 ASM routines
when I was doing data acquisition as fast as
possible on a MINC system. Perused my FORTRAN
code about 6 months ago and had common blocks and
a routine which took "arrays" which were
essential chunks of PDP-11 memory that I'd use as
data buffers and to access data in my ASM
routines directly. Certainly a lot faster than
doing function calls to get at this data but
would now be looked at as very "dangerous" programming.
Considering I was limited to <56 Kb of RAM for
all my code and data I used a very stripped down
version of RT-11 and found it simpler to create a
RAMdisk out of the high memory on the 512 Kb
memory card and wrote a VM driver to stash A/D
data there. For this type of programming one
needs to look at scalability properties of a
system. That 11/23 system looks like a toy now
compared to a cheap FitBit but the MINC had one
job to do and needed to be pushed to its limits
to do it. I documented my code well (or so I
thought) but after 30+ years it took me a while
to figure out what I was doing. For a dedicated
system, code like that is necessary if one
doesn't have the option of getting a more
powerfull machine that can provide the necessary
data acquisition speed as well as allowing "safe"
but much slower code given the need to perform
frequent checks on variables, address bounds,
etc. One needs a machine that can operate in
supervisor and user modes with supervisor memory
protected but each context switch takes time.
Used to be able to do this sort of stuff with
early Windoze but everything tightly sandboxed
now. Now, if I want to do any reasonable speed
data acquisition have to build a microprocessor
system which is fun to code and then connect it
via USB to a Windoze "mainframe" for
analysis. Of course, if one really wants speed,
then one can use Ciarcia's "solder" programming language.
Boris Gimbarzevsky
On 5/29/20 3:41 PM, Fred Cisin via cctalk wrote:
Yes, a pointer to the PC Interrupt Vector Table could be problematic.
>
> C lets you do a lot of things that some other languages will protect you
> from. Accordingly, Allen Holub titled one of his books about C, "Enough
> Rope To Shoot Yourself In The Foot"
> ISBN-10: 0070296898
> ISBN-13: 978-0070296893
Oh, FORTRAN can do likewise--I suspect that most languages can be coaxed
(perhaps with some assembly-language subroutines)to do something nasty.
Two cases in point (but I have lots more). In the CDC 60-bit machines,
one of the most useful functions was LOC(). It passes the address of
the argument. Note that this was basically a single instruction as
FORTRAN uses call-by-reference in most older versions.
The other aspect of the CDC operating systems is that PPMTR looked
periodically at each user's location 1 for system requests. So, it was
a simple matter to use LOC() to obtain a negative subscript into an
array to write and read that location. With the ability to make system
requests directly (and directly address user memory), the sky is the
limit. Indeed several user-written system utilities were written using
just that technique. The CDC iron is word-addressable only.
(Other abuses were the arbitrary target for the ASSIGNed GOTO, but
that's another subject).
Similarly, BASIC, depending on the version, could be abused. One
technique was to use a character array with the BASED attribute (I don't
know if I was the first to invent that keyword, but it was around 1978).
That turned the variable into a pointer and one could change the area
that the variable pointed to with the BASE...AT statement. Several
utilities were written in this fashion, including a few that located the
video refresh buffer and wrote to it directly.
I've been known to do similar nasty things in COBOL.
Side question: How does one create named COMMON in C?
--Chuck
