On 2022-05-24, Dave Froble <davef@tsoft-inc.com> wrote:
> On 5/24/2022 1:31 PM, Simon Clubley wrote:
>>
>> It protects you better than C at the expense of not been able to do
>> everything C does but there are also other languages that help protect
>> you while still allowing you to do the things that C lets you do.
>
> Ok, gauntlet thrown down, and picked up.
>
> Leaving out the specifics of the implementation of DEC Basic, which include not
> thread safe, and other things, I would like to know just what C can do that
> Basic can not do.
>
> I will admit that some nice things such as safe for kernel code, threads, and
> such are not available with the implementation. But what if the exact same
> language was implemented with a new compiler that would produce thread safe and
> kernel safe code was implemented? Then what could C do that Basic could not do?
>

You can't wave away the discussion by claiming some magical new compiler
would solve all the issues with using Basic in kernel mode.

In addition to the answers you have received, Basic also comes with a
heavy RTL which is most certainly not suitable for running in kernel mode.

Any such new language capable of running in kernel mode would be Basic
in name only.

We had a discussion recently about building and managing in-memory trees
of objects/records/etc in Basic. Your solution was to use a contiguous
array of records with internal record numbers within the array to move
around in the structure.

If you can't even do proper memory management in DEC Basic, then it sure
as hell isn't going anywhere near a device driver or something else that
needs to maintain a proper in-memory tree.

I should also point out that, even on an OS that used Basic as its primary
userland programming language (ie: RSTS/E), all the kernel stuff was still
written in Macro-11.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Wed, 2022-05-25 at 16:21 +0200, Johnny Billquist wrote:
> The 16 bit indirect pointers might sound good, but it's partially
> since the 6502 only have 8 bit registers, so you are forced to go
> there.And of course, another implication is that the stack can only
> be 256 bytes on the 6502 as well...

The 65816 attempted to fix these issues by allowing muitple stacks,
IIRC
--
Tactical Nuclear Kittens

On 5/25/2022 2:00 PM, Simon Clubley wrote:
> On 2022-05-24, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 5/24/2022 1:31 PM, Simon Clubley wrote:
>>>
>>> It protects you better than C at the expense of not been able to do
>>> everything C does but there are also other languages that help protect
>>> you while still allowing you to do the things that C lets you do.
>>
>> Ok, gauntlet thrown down, and picked up.
>>
>> Leaving out the specifics of the implementation of DEC Basic, which include not
>> thread safe, and other things, I would like to know just what C can do that
>> Basic can not do.
>>
>> I will admit that some nice things such as safe for kernel code, threads, and
>> such are not available with the implementation. But what if the exact same
>> language was implemented with a new compiler that would produce thread safe and
>> kernel safe code was implemented? Then what could C do that Basic could not do?
>>
>
> You can't wave away the discussion by claiming some magical new compiler
> would solve all the issues with using Basic in kernel mode.

Sure I can.

Language syntax is one thing. How it's implemented is another.

Not just Basic has multiple implementations of the language. How many
implementations of C are there?

> In addition to the answers you have received, Basic also comes with a
> heavy RTL which is most certainly not suitable for running in kernel mode.

Yes, DEC/Compaq/HP/VSI Basic has that implementation, and for a jack of all
trades, that may be fine, while it does preclude some usage, such as OS
implementation.

> Any such new language capable of running in kernel mode would be Basic
> in name only.

That doesn't make any sense. There are already various implementations of Basic
that are rather different. But the syntax and such is rather similar.

> We had a discussion recently about building and managing in-memory trees
> of objects/records/etc in Basic. Your solution was to use a contiguous
> array of records with internal record numbers within the array to move
> around in the structure.

That was one suggestion, and if I remember correctly, I mentioned others. I
seem to recall mentioning allocating memory and using pointers. You like to
pick and choose only that which supports your claims?

When there are multiple methods to do a job, what is wrong with choosing the
simplest and easiest, if it will do the job?

> If you can't even do proper memory management in DEC Basic, then it sure
> as hell isn't going anywhere near a device driver or something else that
> needs to maintain a proper in-memory tree.

Define "proper memory management". You may see that your claim is bullshit.

> I should also point out that, even on an OS that used Basic as its primary
> userland programming language (ie: RSTS/E), all the kernel stuff was still
> written in Macro-11.

As was most OSs in that time frame. Your mention of Basic+ shows that there are
multiple implementations of Basic, in case you were not aware.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 05/25/22 15:21, Johnny Billquist wrote:
> On 2022-05-25 14:02, chris wrote:
>> On 05/25/22 09:22, John Dallman wrote:
>>> In article<t6j88d$1136$1@gioia.aioe.org>, chris-nospam@tridac.net
>>> (chris)
>>> wrote:
>>>
>>>> What made the 6502 a bit special was the variety of addressing
>>>> modes . . . Not even close to the PDP11 of the time, but probably
>>>> the best they could do with the process technology of the day..
>>>
>>> You could build more complex 8-bit CPUs at the time, such as the 8080.
>>> The 6502 was specifically designed to be easy and cheap to produce as a
>>> microcontroller. Its success in home computers was because it turned out
>>> to be good at running interpreters.
>>
>> I would suggest that was because of the indirect addressing modes, which
>> in theory, allowed up to 128 x 16 bit pointers in page zero. The
>> other thing that made 6502 faster than Intel of the time was the fact
>> that condition codes, zero, negative etc, were set on a load, as pdp11
>> in fact (bringing it back on topic), whereas the wooden 8080 and similar
>> needed a tst instruction before a branch. This alone saves a lot of
>> cycles in a tight instruction stream.
>
> The 16 bit indirect pointers might sound good, but it's partially since
> the 6502 only have 8 bit registers, so you are forced to go there. And
> of course, another implication is that the stack can only be 256 bytes
> on the 6502 as well...
>
> Setting of condition codes on load is a good point though.
> This is somewhat offset by the fact that the Z80 (can't remember if the
> 8080 had it) block instructions, which in the end makes for even tighter
> operations, since they already do bounds checking, and updating
> pointers, in addition to either moving or checking.
> Classic things like moving a nul-terminated string on a Z80:
>
> LD HL,SRC
> LD DE,DST
> LD BC,MAX
> XOR A
> LOOP: CP (HL)
> JR Z,DONE
> LDI
> JP PE,LOOP
> DONE:
>
> Four instructions isn't too shabby. Not sure how many that would become
> with 6502. And you actually have a choice without extra cost on what
> character to terminate on. Don't have to be NUL.
>
> Of course, just searching for a byte is just a single instruction
> (CPIR), so that I won't even mention any further.
>
> Basically, as long as you only have to deal with 8 bit data, and you
> don't really even want to deal with 16 bit pointers, then the 6502 is
> pretty nice. But it quickly turns ugly from there.
>

Well, we can agree to differ :-). Other things that were an impediment
for the 8080 were the need for +5. -5 and +12v supply, not to mention
the need for a 2 phase clock. That was only fixed with the 8085. Both
those things involve considerable added hardware cost to a project.

I guess what it comes down to is best results are achieved with the
processor you are most familiar with. Z80 was pretty good, but later
Motorola efforts like the 6809 were even more capable.

Much more interesting time in computing, with new developments almost
every month, but it was the 68000 and later that made possible
affordable desktop workstations for technical work.

>
>>> John (who was one of two students who wrote a FORTH interpreter in a
>>> day)
>>
>> That is a great achievement, but how big was the dictionary ?. A
>> friend wrote a 68000 cross assembler on an Apple II in a few days
>> and it produced good code.
>
> Hmm? Produce good code? It's an assembler, right? So it should literally
> just be a 1:1 mapping between the source and the code generated. There
> isn't exactly anything more an assembler would do.
>
> But anyway, writing a full assembler is still some work. Well done.
>
>> All history now, but still feel privileged to have been part of
>> that tech revolution is some small way. We thought anything was
>> possible at the time...
>
> Anything is still possible. It has only become more difficult. :-)
>

Far too much abstraction and not enough metal at every step now...

Chris

> Johnny

On 5/25/2022 4:06 PM, Dave Froble wrote:
> On 5/25/2022 2:00 PM, Simon Clubley wrote:
>> On 2022-05-24, Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 5/24/2022 1:31 PM, Simon Clubley wrote:
>>>>
>>>> It protects you better than C at the expense of not been able to do
>>>> everything C does but there are also other languages that help protect
>>>> you while still allowing you to do the things that C lets you do.
>>>
>>> Ok, gauntlet thrown down, and picked up.
>>>
>>> Leaving out the specifics of the implementation of DEC Basic, which
>>> include not
>>> thread safe, and other things, I would like to know just what C can
>>> do that
>>> Basic can not do.
>>>
>>> I will admit that some nice things such as safe for kernel code,
>>> threads, and
>>> such are not available with the implementation.  But what if the
>>> exact same
>>> language was implemented with a new compiler that would produce
>>> thread safe and
>>> kernel safe code was implemented?  Then what could C do that Basic
>>> could not do?
>>
>> You can't wave away the discussion by claiming some magical new compiler
>> would solve all the issues with using Basic in kernel mode.
>
> Sure I can.
>
> Language syntax is one thing.  How it's implemented is another.

Yes.

It seems obvious to me that a Basic compiler could be implemented
that could do it.

I mean what characterize Basic? A few control structure, a few
data types, a few operators and a few functions.

That does not prevent anything. As Basic is not excluding any
extensions.

One could create a Basic with a pointer type etc. that
allowed kernel code.

But unless such a compiler is created then it has
no practical impact.

Arne

gah4 <gah4@u.washington.edu> writes:

> On Tuesday, May 24, 2022 at 3:31:58 PM UTC-7, Rich Alderson wrote:

> (snip)

>> The 1401 was my first computer, and I don't recall using octal. It was a BCD
>> computer, and we learned the character codes for that kind of hacking...

> Looking at:

> https://en.wikipedia.org/wiki/IBM_1401#Character_and_op_codes

> it seems both are right.

> Arithmetic and addressing is BCD. Characters and opcodes use all
> six bits (BA8421) and could be represented in octal.

Could be, but never were in my experience. That would have meant mixing bases,
and the 14xx family are *decimal* machines.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On Wednesday, May 25, 2022 at 6:40:13 PM UTC-7, Rich Alderson wrote:

(snip, I wrote)
> > it seems both are right.
> > Arithmetic and addressing is BCD. Characters and opcodes use all
> > six bits (BA8421) and could be represented in octal.

> Could be, but never were in my experience. That would have meant mixing bases,
> and the 14xx family are *decimal* machines.

It does seem an unusual machine, but mixed base seems to be the way.

Memory comes as 4000, 8000, 12000, or 16000 characters.
Addresses have three decimal digits, and then four binary digits,
the BA bits of the high and low digit. So already mixed base.

But there are 64 opcodes in six bits, the BA8421 bits, and there
are 64 characters in the character set, with punch codes for them.

The examples in the Wikipedia page use octal for instructions, but
I didn't look up any IBM manuals.

I believe that there are machines with decimal coded opcodes,
but this doesn't seem to be one of them. Yes, fun with mixed bases.

On Wednesday, May 25, 2022 at 6:40:13 PM UTC-7, Rich Alderson wrote:

(snip)

> > Arithmetic and addressing is BCD. Characters and opcodes use all
> > six bits (BA8421) and could be represented in octal.

> Could be, but never were in my experience. That would have meant mixing bases,
> and the 14xx family are *decimal* machines.

Looking at an actual IBM manual, it seems that the 64 opcodes map to
the 64 characters in the character set, and those characters are used
to represent them. That is, base 64.

Some others might represent those in octal, but yes I don't see IBM doing it.

On 2022-05-25, Dave Froble <davef@tsoft-inc.com> wrote:
> On 5/25/2022 2:00 PM, Simon Clubley wrote:
>> On 2022-05-24, Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 5/24/2022 1:31 PM, Simon Clubley wrote:
>>>>
>>>> It protects you better than C at the expense of not been able to do
>>>> everything C does but there are also other languages that help protect
>>>> you while still allowing you to do the things that C lets you do.
>>>
>>> Ok, gauntlet thrown down, and picked up.
>>>
>>> Leaving out the specifics of the implementation of DEC Basic, which include not
>>> thread safe, and other things, I would like to know just what C can do that
>>> Basic can not do.
>>>
>>> I will admit that some nice things such as safe for kernel code, threads, and
>>> such are not available with the implementation. But what if the exact same
>>> language was implemented with a new compiler that would produce thread safe and
>>> kernel safe code was implemented? Then what could C do that Basic could not do?
>>>
>>
>> You can't wave away the discussion by claiming some magical new compiler
>> would solve all the issues with using Basic in kernel mode.
>
> Sure I can.
>
> Language syntax is one thing. How it's implemented is another.
>
> Not just Basic has multiple implementations of the language. How many
> implementations of C are there?
>
>> In addition to the answers you have received, Basic also comes with a
>> heavy RTL which is most certainly not suitable for running in kernel mode.
>
> Yes, DEC/Compaq/HP/VSI Basic has that implementation, and for a jack of all
> trades, that may be fine, while it does preclude some usage, such as OS
> implementation.
>
>> Any such new language capable of running in kernel mode would be Basic
>> in name only.
>
> That doesn't make any sense. There are already various implementations of Basic
> that are rather different. But the syntax and such is rather similar.
>

Basic implementations all have various features in common, such as (for
example) more higher-level and dynamic string handling than in C.
To support that and other functionality requires a serious runtime behind
it, regardless of the Basic dialect in use.

In kernel mode, even C on VMS only has a restricted runtime available and
that was functionality that DEC had to add in.

Due to runtime limitations, any Basic running in kernel mode is going to
be basically C in functionality, so you would be writing code that looked
like Basic syntax on the surface, but was actually C style code where you
had to specify _everything_ that was going on.

That's what I mean by a kernel-mode Basic being Basic in name only.

>> We had a discussion recently about building and managing in-memory trees
>> of objects/records/etc in Basic. Your solution was to use a contiguous
>> array of records with internal record numbers within the array to move
>> around in the structure.
>
> That was one suggestion, and if I remember correctly, I mentioned others. I
> seem to recall mentioning allocating memory and using pointers. You like to
> pick and choose only that which supports your claims?
>

No. One of the questions of that discussion was how could you point a Basic
record structure at a random point in memory and then access the memory
at that location through the record structure only. A followup question was
how could you chain a set of instances of those record types with a pointer
in each record instance chaining to the next instance.

I don't recall ever seeing an answer to those questions.

> When there are multiple methods to do a job, what is wrong with choosing the
> simplest and easiest, if it will do the job?
>
>> If you can't even do proper memory management in DEC Basic, then it sure
>> as hell isn't going anywhere near a device driver or something else that
>> needs to maintain a proper in-memory tree.
>
> Define "proper memory management". You may see that your claim is bullshit.
>

Here's something I have been looking at recently, which is the USB EHCI
specification:

https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/ehci-specification-for-usb.pdf

Look at chapter 3, which documents the data structures for the controller.

Notice how there are multiple chained lists of data structures in memory,
each with its own layout. How would you implement something like that in
DEC Basic ?

In C, you just define a struct data type, and then create pointers of that
data type, or cast from a void * pointer, both within the structure (or a
parent structure) and outside of it. How do you do that in DEC Basic ?

Even if you extend DEC Basic to have proper pointer data types, you still
have the problem that you can't run Basic in kernel mode as-is due to
Basic runtime requirements.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-05-25, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> Yes.
>
> It seems obvious to me that a Basic compiler could be implemented
> that could do it.
>
> I mean what characterize Basic? A few control structure, a few
> data types, a few operators and a few functions.
>
> That does not prevent anything. As Basic is not excluding any
> extensions.
>

Careful Arne. The features that make Basic the language it is come
with a heavy runtime but code running in kernel mode has only a
restricted runtime (even for C) due to the nature of kernel mode.

Take away those features and you are left with a Basic that has
Basic style syntax but with C levels of functionality.

> One could create a Basic with a pointer type etc. that
> allowed kernel code.
>
> But unless such a compiler is created then it has
> no practical impact.
>

And that is absolutely correct provided you extend it to the runtime
as well. The operating systems you wish to run this kernel mode Basic
on would need support adding for even a minimal Basic runtime.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 5/26/22 14:16, Simon Clubley wrote:
>
>
> No. One of the questions of that discussion was how could you point a Basic
> record structure at a random point in memory and then access the memory
> at that location through the record structure only. A followup question was
> how could you chain a set of instances of those record types with a pointer
> in each record instance chaining to the next instance.
>
> I don't recall ever seeing an answer to those questions.
>

I really hate to burst your bubble (well, no, not really :-) but
while cumbersome because it is not the intended use, it is possible
in some dialects of BASIC. In particular, TRS-80 BASIC. Using
combinations of arrays, PEEK(), POKE() and VARPTR() I could certainly
do that.

You need to learn more BASIC. :-)

Oh, and I would need to take a look at the documentation again but I
suspect it could be easily done in Basic09.

bill

On 2022-05-26, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 5/26/22 14:16, Simon Clubley wrote:
>>
>>
>> No. One of the questions of that discussion was how could you point a Basic
>> record structure at a random point in memory and then access the memory
>> at that location through the record structure only. A followup question was
>> how could you chain a set of instances of those record types with a pointer
>> in each record instance chaining to the next instance.
>>
>> I don't recall ever seeing an answer to those questions.
>>
>
>
> I really hate to burst your bubble (well, no, not really :-) but

:-)

> while cumbersome because it is not the intended use, it is possible
> in some dialects of BASIC. In particular, TRS-80 BASIC. Using
> combinations of arrays, PEEK(), POKE() and VARPTR() I could certainly
> do that.
>
> You need to learn more BASIC. :-)
>

Aware of peek and poke in some microcontroller Basic implementations.
They return/set bytes/words/longwords at the memory location specified.
You are not writing kernel code (or application code) in 2022 by doing
the equivalent of "uint32_t *ptr" only in your code instead of using
structures/records that model the memory block at the given location.

As per the question I just asked, how would you define a record
structure and access a block of memory through the record structure
at a random memory location and how would you chain together instances
of these structures in memory ?

In C, it's easy. You define a struct data type with forward links within
the structure as required and with pointers of that data type outside
of the structure as required.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Thursday, May 26, 2022 at 12:16:48 PM UTC-7, Simon Clubley wrote:
> > I really hate to burst your bubble (well, no, not really :-) but
> :-)
> > while cumbersome because it is not the intended use, it is possible
> > in some dialects of BASIC. In particular, TRS-80 BASIC. Using
> > combinations of arrays, PEEK(), POKE() and VARPTR() I could certainly
> > do that.
> >
> > You need to learn more BASIC. :-)
> >
> Aware of peek and poke in some microcontroller Basic implementations.
> They return/set bytes/words/longwords at the memory location specified.
> You are not writing kernel code (or application code) in 2022 by doing
> the equivalent of "uint32_t *ptr" only in your code instead of using
> structures/records that model the memory block at the given location.
>
> As per the question I just asked, how would you define a record
> structure and access a block of memory through the record structure
> at a random memory location and how would you chain together instances
> of these structures in memory ?

As an American, I didn't get a chance to learn about the wonders of BBC BASIC until quite recently, when I had a chance to teach myself RISC OS via the Raspberry Pi edition of the new open-source OS. Quite an interesting OS.

Sophie Wilson is a genius in my book for two reasons: the clever design of the original ARM instruction set and BBC BASIC. The language has a few odd choices, like case sensitivity, but some amazing features, including a built-in assembler (6502 for the original, ARM for RISC OS), which beats the heck out of typing in lines of decimal or hex digits of machine code from a magazine. Instead, you got to type in the assembly code and maybe learn something. I wish I'd had an Archimedes as a kid.

BBC BASIC is structured and people did use it on RISC OS for GUI programming (via the OS's "WIMP" APIs) but in a fairly ugly way: you can DIM a block of bytes and then read/write offsets into it, and in so doing fill in the OS's data structures in the same way that an asm programmer would, although not in the way that you or I would want or expect from a HLL.

The one thing BBC BASIC doesn't readily allow (and VMS BASIC does): callbacks from native code into BASIC. The only reason it works reasonably well for RISC OS GUI programs is that the GUI is cooperatively multitasking, and the event loop, including "wait for next event", can be managed from the BASIC side.

Regards,
Jake

On Thursday, May 26, 2022 at 11:46:07 AM UTC-7, Bill Gunshannon wrote:

(snip)

> You need to learn more BASIC. :-)
> Oh, and I would need to take a look at the documentation again but I
> suspect it could be easily done in Basic09.

Years ago, I had OS/9 running on my TRS-80 color computer.

The manual is here:

https://colorcomputerarchive.com/repo/Documents/Manuals/Programming/BASIC09%20Programming%20Language%20Reference%20Manual%20-%20Revision%20H%20(Microware%20System%20Corp).pdf

I adapted some Teac FD55F, 80 track two side, floppy drives to it, rewriting the floppy driver to use them.
(That is, about the time that MS-DOS was using 40 track drives.)

I had both BASIC09 and the OS/9 C compiler running.
I suspect I still have the disks, and could get it running again.

And yes, BASIC09 is not much like other versions of BASIC.

gah4 <gah4@u.washington.edu> writes:

> On Wednesday, May 25, 2022 at 6:40:13 PM UTC-7, Rich Alderson wrote:

> (snip)

>>> Arithmetic and addressing is BCD. Characters and opcodes use all
>>> six bits (BA8421) and could be represented in octal.

>> Could be, but never were in my experience. That would have meant mixing
>> bases, and the 14xx family are *decimal* machines.

> Looking at an actual IBM manual, it seems that the 64 opcodes map to
> the 64 characters in the character set, and those characters are used
> to represent them. That is, base 64.

> Some others might represent those in octal, but yes I don't see IBM doing it.

Yeah, it wasn't called "base 64". It was called "BCD", and they were simply
treated as alphanumerics and special characters.

The B bit corresponds to the 11 zone punch on a card, the A bit to the 0 zone
punch, and BA corresponds to the 12 zone punch.

All 0's is the SPACE character; the "0" character is the 8+2 bits.

NB: The card codes on the "96 column cards" used by the System/3 are the same
as the 14xx BCD representation in memory.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On 5/26/22 15:16, Simon Clubley wrote:
> On 2022-05-26, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 5/26/22 14:16, Simon Clubley wrote:
>>>
>>>
>>> No. One of the questions of that discussion was how could you point a Basic
>>> record structure at a random point in memory and then access the memory
>>> at that location through the record structure only. A followup question was
>>> how could you chain a set of instances of those record types with a pointer
>>> in each record instance chaining to the next instance.
>>>
>>> I don't recall ever seeing an answer to those questions.
>>>
>>
>>
>> I really hate to burst your bubble (well, no, not really :-) but
>
> :-)
>
>> while cumbersome because it is not the intended use, it is possible
>> in some dialects of BASIC. In particular, TRS-80 BASIC. Using
>> combinations of arrays, PEEK(), POKE() and VARPTR() I could certainly
>> do that.
>>
>> You need to learn more BASIC. :-)
>>
>
> Aware of peek and poke in some microcontroller Basic implementations.
> They return/set bytes/words/longwords at the memory location specified.
> You are not writing kernel code (or application code) in 2022 by doing
> the equivalent of "uint32_t *ptr" only in your code instead of using
> structures/records that model the memory block at the given location.
>
> As per the question I just asked, how would you define a record
> structure and access a block of memory through the record structure
> at a random memory location and how would you chain together instances
> of these structures in memory ?
>
> In C, it's easy. You define a struct data type with forward links within
> the structure as required and with pointers of that data type outside
> of the structure as required.

So, tell me, would you consider a complete Virtual Machine that emulates
a hardware architecture and contains all the primitives for I/O, math
and other necessary function to be an Operating System?

bill

On 5/26/2022 2:24 PM, Simon Clubley wrote:
> On 2022-05-25, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> Yes.
>>
>> It seems obvious to me that a Basic compiler could be implemented
>> that could do it.
>>
>> I mean what characterize Basic? A few control structure, a few
>> data types, a few operators and a few functions.
>>
>> That does not prevent anything. As Basic is not excluding any
>> extensions.
>>
>
> Careful Arne. The features that make Basic the language it is come
> with a heavy runtime but code running in kernel mode has only a
> restricted runtime (even for C) due to the nature of kernel mode.
>
> Take away those features and you are left with a Basic that has
> Basic style syntax but with C levels of functionality.

Besides certain new features being required, then some features
would not be allowed in kernel context.

But that would apply to any language used for that
purpose - it is not a matter of *if* but a matter of *how much*
has to be avoided.

And it is not really surprising that low level functionality
is required to write low level code.

If you decide to call low level code for C level code, then
it sound C'ish, but the functionality is not inherent C'ish
in nature.

>> One could create a Basic with a pointer type etc. that
>> allowed kernel code.
>>
>> But unless such a compiler is created then it has
>> no practical impact.
>
> And that is absolutely correct provided you extend it to the runtime
> as well. The operating systems you wish to run this kernel mode Basic
> on would need support adding for even a minimal Basic runtime.

Lots of things are possible for a hypothetical compiler that
is not expected to be implemented.

Arne

On Thursday, May 26, 2022 at 2:54:31 PM UTC-7, Rich Alderson wrote:

(snip)

> > Looking at an actual IBM manual, it seems that the 64 opcodes map to
> > the 64 characters in the character set, and those characters are used
> > to represent them. That is, base 64.
>
> > Some others might represent those in octal, but yes I don't see IBM doing it.

> Yeah, it wasn't called "base 64". It was called "BCD", and they were simply
> treated as alphanumerics and special characters.
> The B bit corresponds to the 11 zone punch on a card, the A bit to the 0 zone
> punch, and BA corresponds to the 12 zone punch.
> All 0's is the SPACE character; the "0" character is the 8+2 bits.

The 704 uses a 48 character version of BCD, though I didn't match
up the character codes. The documentation of opcodes uses octal.

I didn't see actual assembler output for either one, but in the instruction
tables the BCD character is used as the numeric opcode for the 1401,
where others would put the octal (or later hexadecimal) opcode.

Now, since the 704 only has 48 characters in its BCD, not enough for
all the opcodes, maybe that isn't so surprising.

> NB: The card codes on the "96 column cards" used by the System/3 are the same
> as the 14xx BCD representation in memory.

It seems that System/3 cards can be either six bit BCD, or 8 bit EBCDIC.
In the latter case, the extra two rows of punches go above, where the printed
text goes. I am not sure how the two codes work together.

I do remember knowing, not so many years ago, that there was a System/3
card read/punch for the 360/20, but never saw one.

The 704 has some strange features with its character code. Among others,
they used even parity tape (must have seemed like a good idea) where you can't
write the character with all bits zero. (No transitions means no clock.)

I didn't look to see what the 1401 ALU generates for its decimal output,
but I presume the 8-2 code.

On 5/26/2022 2:16 PM, Simon Clubley wrote:
> On 2022-05-25, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 5/25/2022 2:00 PM, Simon Clubley wrote:
>>> On 2022-05-24, Dave Froble <davef@tsoft-inc.com> wrote:
>>>> On 5/24/2022 1:31 PM, Simon Clubley wrote:
>>>>>
>>>>> It protects you better than C at the expense of not been able to do
>>>>> everything C does but there are also other languages that help protect
>>>>> you while still allowing you to do the things that C lets you do.
>>>>
>>>> Ok, gauntlet thrown down, and picked up.
>>>>
>>>> Leaving out the specifics of the implementation of DEC Basic, which include not
>>>> thread safe, and other things, I would like to know just what C can do that
>>>> Basic can not do.
>>>>
>>>> I will admit that some nice things such as safe for kernel code, threads, and
>>>> such are not available with the implementation. But what if the exact same
>>>> language was implemented with a new compiler that would produce thread safe and
>>>> kernel safe code was implemented? Then what could C do that Basic could not do?
>>>>
>>>
>>> You can't wave away the discussion by claiming some magical new compiler
>>> would solve all the issues with using Basic in kernel mode.
>>
>> Sure I can.
>>
>> Language syntax is one thing. How it's implemented is another.
>>
>> Not just Basic has multiple implementations of the language. How many
>> implementations of C are there?
>>
>>> In addition to the answers you have received, Basic also comes with a
>>> heavy RTL which is most certainly not suitable for running in kernel mode.
>>
>> Yes, DEC/Compaq/HP/VSI Basic has that implementation, and for a jack of all
>> trades, that may be fine, while it does preclude some usage, such as OS
>> implementation.
>>
>>> Any such new language capable of running in kernel mode would be Basic
>>> in name only.
>>
>> That doesn't make any sense. There are already various implementations of Basic
>> that are rather different. But the syntax and such is rather similar.
>>
>
> Basic implementations all have various features in common, such as (for
> example) more higher-level and dynamic string handling than in C.
> To support that and other functionality requires a serious runtime behind
> it, regardless of the Basic dialect in use.

And your point is?

> In kernel mode, even C on VMS only has a restricted runtime available and
> that was functionality that DEC had to add in.

Which gets mentioned not so often. Without that, C also cannot be used for
kernel mode code.

> Due to runtime limitations, any Basic running in kernel mode is going to
> be basically C in functionality, so you would be writing code that looked
> like Basic syntax on the surface, but was actually C style code where you
> had to specify _everything_ that was going on.
>
> That's what I mean by a kernel-mode Basic being Basic in name only.

Same for C, right?

>>> We had a discussion recently about building and managing in-memory trees
>>> of objects/records/etc in Basic. Your solution was to use a contiguous
>>> array of records with internal record numbers within the array to move
>>> around in the structure.
>>
>> That was one suggestion, and if I remember correctly, I mentioned others. I
>> seem to recall mentioning allocating memory and using pointers. You like to
>> pick and choose only that which supports your claims?
>>
>
> No. One of the questions of that discussion was how could you point a Basic
> record structure at a random point in memory and then access the memory
> at that location through the record structure only.

Not sure what you're asking. A defined record structure has an address, and
data in the structure can be acessed within the structure, just like any variable.

> A followup question was
> how could you chain a set of instances of those record types with a pointer
> in each record instance chaining to the next instance.

In a Basic record structure, pointers are not needed.

> I don't recall ever seeing an answer to those questions.
>
>> When there are multiple methods to do a job, what is wrong with choosing the
>> simplest and easiest, if it will do the job?
>>
>>> If you can't even do proper memory management in DEC Basic, then it sure
>>> as hell isn't going anywhere near a device driver or something else that
>>> needs to maintain a proper in-memory tree.
>>
>> Define "proper memory management". You may see that your claim is bullshit.
>>
>
> Here's something I have been looking at recently, which is the USB EHCI
> specification:
>
> https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/ehci-specification-for-usb.pdf
>
> Look at chapter 3, which documents the data structures for the controller.
>
> Notice how there are multiple chained lists of data structures in memory,
> each with its own layout. How would you implement something like that in
> DEC Basic ?
>
> In C, you just define a struct data type, and then

I don't seem to understand
"create pointers of that data type"

, or cast from a void * pointer, both within the structure (or a
> parent structure) and outside of it. How do you do that in DEC Basic ?

Basic can call LIB$GET_VM

LIB$GET_VM

The Allocate Virtual Memory routine allocates a specified number
of contiguous bytes in the program region and returns the 32-bit
virtual address of the first byte allocated.

Of course, then the programmer is tasked with all control of such memory,
including dealocating it (LIB$FREE_VM).

Unless absolutely necessary, I'd never do that. Sort of goes against "safer
programming". Puts much more responsibility on the programmer. But it can be done.

As of now, in Basic, a pointer/address is a longword. No problem.

> Even if you extend DEC Basic to have proper pointer data types, you still
> have the problem that you can't run Basic in kernel mode as-is due to
> Basic runtime requirements.

Unless using the special RTL, you cannot do that in C either.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 5/26/2022 3:16 PM, Simon Clubley wrote:
> On 2022-05-26, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 5/26/22 14:16, Simon Clubley wrote:
>>>
>>>
>>> No. One of the questions of that discussion was how could you point a Basic
>>> record structure at a random point in memory and then access the memory
>>> at that location through the record structure only. A followup question was
>>> how could you chain a set of instances of those record types with a pointer
>>> in each record instance chaining to the next instance.
>>>
>>> I don't recall ever seeing an answer to those questions.
>>>
>>
>>
>> I really hate to burst your bubble (well, no, not really :-) but
>
> :-)
>
>> while cumbersome because it is not the intended use, it is possible
>> in some dialects of BASIC. In particular, TRS-80 BASIC. Using
>> combinations of arrays, PEEK(), POKE() and VARPTR() I could certainly
>> do that.
>>
>> You need to learn more BASIC. :-)
>>
>
> Aware of peek and poke in some microcontroller Basic implementations.
> They return/set bytes/words/longwords at the memory location specified.
> You are not writing kernel code (or application code) in 2022 by doing
> the equivalent of "uint32_t *ptr" only in your code instead of using
> structures/records that model the memory block at the given location.
>
> As per the question I just asked, how would you define a record
> structure and access a block of memory through the record structure
> at a random memory location and how would you chain together instances
> of these structures in memory ?

Ok, I think I now understand what you're asking. You want to define some
structure, and have it overlay (my term) some device, or such.

Not sure I could do that with the DEC Basic RECORD structure. Not sure I cannot
either.

I do have some experience with assigning labels in an I/O buffer, by mis-using
string descriptors.

:-)

If I studied the concept a bit, perhaps I'd have a batter answer for you. For
now, perhaps I'm just too lazy.

> In C, it's easy. You define a struct data type with forward links within
> the structure as required and with pointers of that data type outside
> of the structure as required.
>
> Simon.
>

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 05/26/22 20:16, Simon Clubley wrote:
> On 2022-05-26, Bill Gunshannon<bill.gunshannon@gmail.com> wrote:
>> On 5/26/22 14:16, Simon Clubley wrote:
>>>
>>>
>>> No. One of the questions of that discussion was how could you point a Basic
>>> record structure at a random point in memory and then access the memory
>>> at that location through the record structure only. A followup question was
>>> how could you chain a set of instances of those record types with a pointer
>>> in each record instance chaining to the next instance.
>>>
>>> I don't recall ever seeing an answer to those questions.
>>>
>>
>>
>> I really hate to burst your bubble (well, no, not really :-) but
>
> :-)
>
>> while cumbersome because it is not the intended use, it is possible
>> in some dialects of BASIC. In particular, TRS-80 BASIC. Using
>> combinations of arrays, PEEK(), POKE() and VARPTR() I could certainly
>> do that.
>>
>> You need to learn more BASIC. :-)
>>
>
> Aware of peek and poke in some microcontroller Basic implementations.
> They return/set bytes/words/longwords at the memory location specified.
> You are not writing kernel code (or application code) in 2022 by doing
> the equivalent of "uint32_t *ptr" only in your code instead of using
> structures/records that model the memory block at the given location.
>
> As per the question I just asked, how would you define a record
> structure and access a block of memory through the record structure
> at a random memory location and how would you chain together instances
> of these structures in memory ?
>
> In C, it's easy. You define a struct data type with forward links within
> the structure as required and with pointers of that data type outside
> of the structure as required.

Quite, and sop for accessing io devices. Assuming the register set is
more of less contiguous in memory, typedef a structure with padding as
required to take account of register sizes and gaps, then instantiate
by declaring a pointer to the structure equal to the base address of
the register set. Where register set is scattered across address space,
as in some Hitachi embedded processors, structure members are defined
as the address of the register, not its offset.

A very good book that originally opened my eyes as to the power of C and
abstraction was:

Data Structures, an Advanced Approach Using C
Jeffrey Esakov and Tom Weiss
Prentice Hall, 1989
ISBN: 0-13199043-8

Well worth a look even for experts :-)...

Chris

>
> Simon.
>

On 2022-05-26, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 5/26/22 15:16, Simon Clubley wrote:
>>
>> Aware of peek and poke in some microcontroller Basic implementations.
>> They return/set bytes/words/longwords at the memory location specified.
>> You are not writing kernel code (or application code) in 2022 by doing
>> the equivalent of "uint32_t *ptr" only in your code instead of using
>> structures/records that model the memory block at the given location.
>>
>> As per the question I just asked, how would you define a record
>> structure and access a block of memory through the record structure
>> at a random memory location and how would you chain together instances
>> of these structures in memory ?
>>
>> In C, it's easy. You define a struct data type with forward links within
>> the structure as required and with pointers of that data type outside
>> of the structure as required.
>
> So, tell me, would you consider a complete Virtual Machine that emulates
> a hardware architecture and contains all the primitives for I/O, math
> and other necessary function to be an Operating System?
>

No.

The operating system is what runs on top of that emulated environment.

I don't understand how this is related to this thread however.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-05-27, Dave Froble <davef@tsoft-inc.com> wrote:
> On 5/26/2022 3:16 PM, Simon Clubley wrote:
>>
>> Aware of peek and poke in some microcontroller Basic implementations.
>> They return/set bytes/words/longwords at the memory location specified.
>> You are not writing kernel code (or application code) in 2022 by doing
>> the equivalent of "uint32_t *ptr" only in your code instead of using
>> structures/records that model the memory block at the given location.
>>
>> As per the question I just asked, how would you define a record
>> structure and access a block of memory through the record structure
>> at a random memory location and how would you chain together instances
>> of these structures in memory ?
>
> Ok, I think I now understand what you're asking. You want to define some
> structure, and have it overlay (my term) some device, or such.
>

That's exactly right David. And to go beyond the register block mapping,
the device itself may have its own data structures that are mapped into
system memory, and for which the driver is responsible for maintaining,
as in the EHCI example I pointed you to.

You said Basic could do everything C can, so I gave you an example of
something that is common in C and asked how you would do the same thing
in DEC Basic.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 5/27/2022 8:55 AM, Simon Clubley wrote:
> On 2022-05-27, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 5/26/2022 3:16 PM, Simon Clubley wrote:
>>>
>>> Aware of peek and poke in some microcontroller Basic implementations.
>>> They return/set bytes/words/longwords at the memory location specified.
>>> You are not writing kernel code (or application code) in 2022 by doing
>>> the equivalent of "uint32_t *ptr" only in your code instead of using
>>> structures/records that model the memory block at the given location.
>>>
>>> As per the question I just asked, how would you define a record
>>> structure and access a block of memory through the record structure
>>> at a random memory location and how would you chain together instances
>>> of these structures in memory ?
>>
>> Ok, I think I now understand what you're asking. You want to define some
>> structure, and have it overlay (my term) some device, or such.
>>
>
> That's exactly right David. And to go beyond the register block mapping,
> the device itself may have its own data structures that are mapped into
> system memory, and for which the driver is responsible for maintaining,
> as in the EHCI example I pointed you to.
>
> You said Basic could do everything C can, so I gave you an example of
> something that is common in C and asked how you would do the same thing
> in DEC Basic.
>
> Simon.
>

Ok Simon, you have me at a distinct disadvantage here. I have never worked with
devices and such. My experience is in database design and implementation, and
business types of applications.

However, with some knowledge and experience with the types of things you are
discussing, I just might figure out how to accomplish them. I will confess, I
might have to go a bit outside what the language allows, but, an address is an
address, and if the address is known, data at that address can be manipulated.

I'd also say that using such techniques just might be a poor practice, since if
the next programmer to touch such code didn't fully understand what was being
done, things would go downhill quit rapidly. So I have to admit that C just
might have better functionality in some cases.

But being a bit stubborn, Basic just might have some capabilities that C does
not, so, from some perspectives, that just might be a counter argument.
However, that's not what I claimed, so perhaps I might have to wipe some egg
from my face.

Unable to stifle all my defiance, I'm sure I could do it in Macro-32.

:-)

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 5/27/22 08:47, Simon Clubley wrote:
> On 2022-05-26, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 5/26/22 15:16, Simon Clubley wrote:
>>>
>>> Aware of peek and poke in some microcontroller Basic implementations.
>>> They return/set bytes/words/longwords at the memory location specified.
>>> You are not writing kernel code (or application code) in 2022 by doing
>>> the equivalent of "uint32_t *ptr" only in your code instead of using
>>> structures/records that model the memory block at the given location.
>>>
>>> As per the question I just asked, how would you define a record
>>> structure and access a block of memory through the record structure
>>> at a random memory location and how would you chain together instances
>>> of these structures in memory ?
>>>
>>> In C, it's easy. You define a struct data type with forward links within
>>> the structure as required and with pointers of that data type outside
>>> of the structure as required.
>>
>> So, tell me, would you consider a complete Virtual Machine that emulates
>> a hardware architecture and contains all the primitives for I/O, math
>> and other necessary function to be an Operating System?
>>
>
> No.
>
> The operating system is what runs on top of that emulated environment.

The example I am thinking of contains the emulated architecture and
everything right up to the user interface. So, it does contain "what
runs on top of that emulated environment".

>
> I don't understand how this is related to this thread however.

Tiny Pascal by Herbert Yuen and Kin-Man Chung. Compiler and Pcode
Interpreter with User Interface all done in NorthStar Basic. In the
September, October and November 1978 issues of Byte Magazine.

bill