Microsoft open sources GWBASIC

[Boris Gimbarzevsky]

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