On 5/24/22 13:41, Simon Clubley wrote:
> On 2022-05-24, Single Stage to Orbit <alex.buell@munted.eu> wrote:
>> On Tue, 2022-05-24 at 01:07 -0700, Ian Miller wrote:
>>>
>>> I preferred BCPL to BASIC on the BBC Computer.
>>
>> I preferred 6502 assembler to BASIC on the Beeb.
>
> It's been a very long time since I used either, but I was left with
> the memory that I preferred Z80 over 6502, although the details have
> been lost to time...

I never liked 6502. I've worked with at least 10 different
architectures and the only one I liked less than the 6502 was
the Pr1me. Much of it's quirks were fixed when native mode
Unix was developed because it included modification to the
micro-code but then Pr1me Corporate squashed it and life in
the Pr1me world returned to the abyss.

bill

On Tue, 24 May 2022 14:47:00 +0100, chris wrote:

> On 05/24/22 11:17, Single Stage to Orbit wrote:
>> On Tue, 2022-05-24 at 01:07 -0700, Ian Miller wrote:
>>> On Monday, May 23, 2022 at 9:24:36 PM UTC+1, Bob Eager wrote:
>>>> On Mon, 23 May 2022 17:46:16 +0000, Simon Clubley wrote:
>>>>
>>>>> On 2022-05-23, Dave Froble<da...@tsoft-inc.com> wrote:
>>>>>>
>>>>>> What safety is there in programming when you remove the need for a
>>>>>> programmer to exercise due diligence and careful practices?
>>>>>>
>>>>>>
>>>>> With that attitude David, you should switch to using C... :-)
>>>> C is for wimps. Try BCPL.
>>>> --
>>>> My posts are my copyright and if @diy_forums or Home Owners' Hub wish
>>>> to copy them they can pay me £1 a message.
>>>> Use the BIG mirror service in the UK: http://www.mirrorservice.org
>>>> *lightning surge protection* - a w_tom conductor
>>>
>>> I preferred BCPL to BASIC on the BBC Computer.
>>
>> I preferred 6502 assembler to BASIC on the Beeb.
>
> I preferred 6502 asm and macro 11 to anything else I had access to at
> time.
>
> The rest of you all were lucky :-)...

I have lost count of the number of assembly languages I have used. But
they included some DEC ones: PAL-8, Macro-11, Macro-32, Macro-10...as
well as 6502, which is probably the lowest level (ah, but there was
8080...).

And some obscure ones - not many have used SFL and the MAPLE assembler.

--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

On Tuesday, May 24, 2022 at 12:10:14 PM UTC-7, Bill Gunshannon wrote:

(snip)

> I never liked 6502. I've worked with at least 10 different
> architectures and the only one I liked less than the 6502 was
> the Pr1me. Much of it's quirks were fixed when native mode
> Unix was developed because it included modification to the
> micro-code but then Pr1me Corporate squashed it and life in
> the Pr1me world returned to the abyss.

The 6502 was designed for embedded processing, and some people
who do that seem to like it more than others.

The 8 bit stack pointer and 8 bit index registers, compared to the 16
bit versions in the 6800 can be less convenient for non-embedded use.

The initial price was much less than the 6800, but very quickly the
price of the 6800 came down. The extra work to use the 8 bit
stack pointer and index registers would cost much more in
throughput of programmers than the price difference.

On Tuesday, May 24, 2022 at 11:30:40 AM UTC-7, chris wrote:

(snip)

> What made the 6502 a bit special was the variety of addressing modes,
> which included pre and post indexed addressing. Very useful for
> traversing lists and trees. That and instruction mnemonics
> borrowed from pdp11, even if the architecture was a single 8 bit
> accumulator + 2 index registers. Not even close to the PDP11 of
> the time, but probably the best they could do with the process
> technology of the day..

The 6502 came after the 6800 and 8080, but with 16 bit
index registers and stack pointers.

For embedded programming, the design goal of the 6502
(and probably the 8080 and 6800), such 8 bit registers are
probably fine, as data structures will be smaller.

But for general programming, like on microcomputers
sold for use as computers, that is very inconvenient.

In many case, the only workaround is self-modifying code,
which is inconvenient for everyone.

On 5/24/2022 1:31 PM, Simon Clubley wrote:
> On 2022-05-23, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 5/23/2022 1:46 PM, Simon Clubley wrote:
>>> On 2022-05-23, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>
>>>> What safety is there in programming when you remove the need for a programmer to
>>>> exercise due diligence and careful practices?
>>>>
>>>
>>> With that attitude David, you should switch to using C... :-)
>>>
>>
>> What attitude is that?
>>
>
> Some C programmers say that there's nothing wrong with C and that it's
> your fault if you are not careful enough when writing C code.
>
> I am not one of them because, for me, I continue to use C because it's
> the most viable language for some tasks, not because it is the best
> language for those tasks.
>
>> Think I'll stick to Basic. Does what I need. Has strings built in.
>>
>
> 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?

--
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

Bill Gunshannon <bill.gunshannon@gmail.com> writes:

> On 5/24/22 09:00, Dan Cross wrote:

>> Anything other than machine code in octal is for pikers.

> Learned to do that on the IBM 1401 when I learned Autocoder. Efficiency was
> important in those days and the output from the Autocoder translator had way
> too much fluff. Used to be fun to Compile a utility program written in
> Autocoder, look at the output card deck and then reduce it to one or two
> cards max.

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...

--
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 05/24/22 21:54, gah4 wrote:
> On Tuesday, May 24, 2022 at 11:30:40 AM UTC-7, chris wrote:
>
> (snip)
>
>> What made the 6502 a bit special was the variety of addressing modes,
>> which included pre and post indexed addressing. Very useful for
>> traversing lists and trees. That and instruction mnemonics
>> borrowed from pdp11, even if the architecture was a single 8 bit
>> accumulator + 2 index registers. Not even close to the PDP11 of
>> the time, but probably the best they could do with the process
>> technology of the day..
>
> The 6502 came after the 6800 and 8080, but with 16 bit
> index registers and stack pointers.

Having spent several years programming 6502 for embedded
systems, I can confirm that all the registers on the 6502
were eight bit. Hence the reason for the indirect addressing
modes, which allowed 16 bit pointers in page zero to
access the whole 64K address space. The design goal of 6502
was to get the most mini like functionality into the
smallest chip area, which they succeeded in doing quite well.

Iirc, the 6800 had a single 16 bit index register and the
dual 8 bit accumulators could be concatenated for certain
16 bit operations. Slower than the 6502, but still a very
significant processor family for its time. Still have a
6800 application manual from 1975 somewhere, complete with
asm sources and hardware design for a bar code reader, among
other things.

>
> For embedded programming, the design goal of the 6502
> (and probably the 8080 and 6800), such 8 bit registers are
> probably fine, as data structures will be smaller.
>
> But for general programming, like on microcomputers
> sold for use as computers, that is very inconvenient.
>

Well, many companies, including Apple got started in home
and business computing with the 6502, while Z80 / 8080
enthusiasts started the cpm80 revolution, which led to
the foirst IBM PC with the Intel 8088.

>
> In many case, the only workaround is self-modifying code,
> which is inconvenient for everyone.
>

IME, no one I worked with ever used self modifying code
on the 6502. That's more like PDP8 era stuff...

>
>

On 5/24/22 18:31, Rich Alderson wrote:
> Bill Gunshannon <bill.gunshannon@gmail.com> writes:
>
>> On 5/24/22 09:00, Dan Cross wrote:
>
>>> Anything other than machine code in octal is for pikers.
>
>> Learned to do that on the IBM 1401 when I learned Autocoder. Efficiency was
>> important in those days and the output from the Autocoder translator had way
>> too much fluff. Used to be fun to Compile a utility program written in
>> Autocoder, look at the output card deck and then reduce it to one or two
>> cards max.
>
> 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...
>

Not octal, just machine code. I didn't get octal till the PDP-11
and I do like it. I can do octal math in my head as well as I can
do decimal math.

bill

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.

On 05/24/22 21:54, Dave Froble wrote:
> On 5/24/2022 1:31 PM, Simon Clubley wrote:
>> On 2022-05-23, Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 5/23/2022 1:46 PM, Simon Clubley wrote:
>>>> On 2022-05-23, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>
>>>>> What safety is there in programming when you remove the need for a
>>>>> programmer to
>>>>> exercise due diligence and careful practices?
>>>>>
>>>>
>>>> With that attitude David, you should switch to using C... :-)
>>>>
>>>
>>> What attitude is that?
>>>
>>
>> Some C programmers say that there's nothing wrong with C and that it's
>> your fault if you are not careful enough when writing C code.
>>
>> I am not one of them because, for me, I continue to use C because it's
>> the most viable language for some tasks, not because it is the best
>> language for those tasks.
>>
>>> Think I'll stick to Basic. Does what I need. Has strings built in.
>>>
>>
>> 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.

If I can answer here, nothing in extremis, but is about ease of use.
Its years since I did any basic, but the only way to access memory
or io devices at the time was via peeks and pokes, which
makes it less than optimum for the sort for low level, bare metal
systems programming. I'm sure it could be done in basic, but it
would be hard work. C, in comparison is about as low level as
you like, but also has enough fundamental capability to write very
complex systems, built up in layers, with defined interfaces at
each level. The core of C centers around the concept of
indirection through pointers and structures, that allow a high
degree of abstraction and data hiding, for experienced practitioners.

It may not be ideal for all application level systems, but nothing
gets close in efficiency and productivity terms for low level and
intermediate level work. Its also pretty straightforward to learn
the basics and the often mentioned difficulties with pointers should
be a natural to anyone experienced in assembler programming...

Chris

>
> 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?
>

On 5/24/2022 1:03 PM, Johnny Billquist wrote:
> On 2022-05-23 14:29, Simon Clubley wrote:
>> On 2022-05-20, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>>> On 2022-05-20 17:44:50 +0000, Simon Clubley said:
>>>>
>>>> These days, I avoid this problem in my C code by using the
>>>> uint[8/16/32]_t (and friends) data types.
>>>>
>>>
>>> Same here, where I need to care that much about the integer types.
>>>
>>
>> Person who likes Ada here, remember ? :-)
>>
>> I always care about my types... :-)
>
> In a sense, this is something Ada really got right. You don't declare
> how many bits, signedness and so on you want. You declare your integers
> with the range you need them to have, and let the language/compiler
> figure out how to represent and store them.

Ada and the rest of that "language family" including Pascal and Modula-2.

> And two "integer" types with different ranges are not the same type, or
> even closely related, and you cannot just assign from one type to another.

That applies for Ada type. Not for Ada subtype and Pascal.

But yes - it is a really really strong feature in Ada. True strict
type check.

> However, if you want to interface with hardware, it becomes a little
> messy, since then you do want to specify things in number of bits and
> bytes. Since that's what the hardware have.

It can also be a problem if the code make certain assumptions about
when integer overflow happens.

Sure that would be ugly code. But ugly code has been seen in
real life.

Arne

On 5/24/2022 4:54 PM, Dave Froble wrote:
> On 5/24/2022 1:31 PM, Simon Clubley wrote:
>> On 2022-05-23, Dave Froble <davef@tsoft-inc.com> wrote:
>>> Think I'll stick to Basic.  Does what I need.  Has strings built in.
>>
>> 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?

Probably nothing.

But no such Basic compiler exist.

Which makes it a very theoretical discussion.

Most likely anything could be written in any language
in theory.

Some things may be a bit extra work, but ...

Decisions about what language to use has to be be made
based on what compilers are actually available.

Arne

On 5/24/2022 4:54 PM, Dave Froble wrote:
> On 5/24/2022 1:31 PM, Simon Clubley wrote:
>> On 2022-05-23, Dave Froble <davef@tsoft-inc.com> wrote:
>>> Think I'll stick to Basic.  Does what I need.  Has strings built in.
>>>
>>
>> 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?

It is really two different tools intended for different purposes.

My claim is that:
- it would be silly to try and write an OS kernel or
device drivers in Basic (any existing Basic)
- it would be silly to write a business money
application in C (existing C - not the C that Bill
believe could be created)

And funny enough - it seems like Basic programmers are way
better than C programmers to understand where their preferred
tool does not make sense to use.

Arne

On 5/24/22 20:04, Arne Vajhøj wrote:
> On 5/24/2022 4:54 PM, Dave Froble wrote:
>> On 5/24/2022 1:31 PM, Simon Clubley wrote:
>>> On 2022-05-23, Dave Froble <davef@tsoft-inc.com> wrote:
>>>> Think I'll stick to Basic.  Does what I need.  Has strings built in.
>>>>
>>>
>>> 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?
>
> It is really two different tools intended for different purposes.
>
> My claim is that:
> - it would be silly to try and write an OS kernel or
>   device drivers in Basic (any existing Basic)
> - it would be silly to write a business money
>   application in C (existing C - not the C that Bill
>   believe could be created)

I have never suggested any change to the C language at all.
Safe C was a compiler for the original K&R C as defined in their
first book. It merely enforced good programming practices. The
other changes I have talked about would all be done in the C RTL
and not in the language. And that includes a string library for
use with a string data type that need not be added to the language
because anyone can define one now if they want one. And, to be
honest they could define a string and write library routines to
work with it and never have to use a null terminated string.
But no one seems interested enough to actually do that. They
prefer to continue to complain about null terminated strings and
buffer overflows while blaming the language and not the programmer.

As for business programming in C. I have long been the one to
say "Choose the right tool for the job." C is not now and never
has been the right tool for business applications. And it never
claimed to be.

>
> And funny enough - it seems like Basic programmers are way
> better than C programmers to understand where their preferred
> tool does not make sense to use.

That one I do not agree with. BASIC, like Pascal, was created to
teach basic programming techniques. I really don't think Kemmeny
and Kurtz ever saw it leaving the academic world.

bill

On 25/05/2022 7:55 am, Arne Vajhøj wrote:
> On 5/24/2022 1:03 PM, Johnny Billquist wrote:
>> On 2022-05-23 14:29, Simon Clubley wrote:
>>> On 2022-05-20, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>>>> On 2022-05-20 17:44:50 +0000, Simon Clubley said:
>>>>>
>>>>> These days, I avoid this problem in my C code by using the
>>>>> uint[8/16/32]_t (and friends) data types.
>>>>>
>>>>
>>>> Same here, where I need to care that much about the integer types.
>>>>
>>>
>>> Person who likes Ada here, remember ? :-)
>>>
>>> I always care about my types... :-)
>>
>> In a sense, this is something Ada really got right. You don't declare
>> how many bits, signedness and so on you want. You declare your
>> integers with the range you need them to have, and let the
>> language/compiler figure out how to represent and store them.
>
> Ada and the rest of that "language family" including Pascal and Modula-2.
>
>> And two "integer" types with different ranges are not the same type,
>> or even closely related, and you cannot just assign from one type to
>> another.
>
> That applies for Ada type. Not for Ada subtype and Pascal.
>
> But yes - it is a really really strong feature in Ada. True strict
> type check.
>
>> However, if you want to interface with hardware, it becomes a little
>> messy, since then you do want to specify things in number of bits and
>> bytes. Since that's what the hardware have.
>
> It can also be a problem if the code make certain assumptions about
> when integer overflow happens.
>
> Sure that would be ugly code. But ugly code has been seen in
> real life.
>
> Arne
>
>

COBOL being the best as usual but still needs POINTER and POINTER-64

On 25/05/2022 1:31 am, Simon Clubley wrote:
> On 2022-05-23, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 5/23/2022 1:46 PM, Simon Clubley wrote:
>>> On 2022-05-23, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>
>>>> What safety is there in programming when you remove the need
>>>> for a programmer to exercise due diligence and careful
>>>> practices?
>>>>
>>>
>>> With that attitude David, you should switch to using C... :-)
>>>
>>
>> What attitude is that?
>>
>
> Some C programmers say that there's nothing wrong with C and that
> it's your fault if you are not careful enough when writing C code.
>
> I am not one of them because, for me, I continue to use C because
> it's the most viable language for some tasks, not because it is the
> best language for those tasks.
>
>> Think I'll stick to Basic. Does what I need. Has strings built
>> in.
>>
>
> 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.
>
> Simon.
>

I hate C! But agree wholeheartedly with the expressed sentiments. If I
have to hear another TypeScript wanker try to tell me what's wrong with
Javascript I'll stick their React, NPM, NodeJS, Babel, Redux, Swagger,
loDash . . . up their arse!

On 5/24/2022 10:05 PM, Bill Gunshannon wrote:

> That one I do not agree with.  BASIC, like Pascal, was created to
> teach basic programming techniques.  I really don't think Kemmeny
> and Kurtz ever saw it leaving the academic world.

I work with a Dartmouth grad who remained in contact with Kemeny
while at DEC; I'll ask tomorrow about BASIC (or Basic, which is the current
correct capitialization).

--
-- Rob

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.

John (who was one of two students who wrote a FORTH interpreter in a day)

On 2022-05-25 01:55, Arne Vajhøj wrote:
> On 5/24/2022 1:03 PM, Johnny Billquist wrote:
>> On 2022-05-23 14:29, Simon Clubley wrote:
>>> On 2022-05-20, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>>>> On 2022-05-20 17:44:50 +0000, Simon Clubley said:
>>>>>
>>>>> These days, I avoid this problem in my C code by using the
>>>>> uint[8/16/32]_t (and friends) data types.
>>>>>
>>>>
>>>> Same here, where I need to care that much about the integer types.
>>>>
>>>
>>> Person who likes Ada here, remember ? :-)
>>>
>>> I always care about my types... :-)
>>
>> In a sense, this is something Ada really got right. You don't declare
>> how many bits, signedness and so on you want. You declare your
>> integers with the range you need them to have, and let the
>> language/compiler figure out how to represent and store them.
>
> Ada and the rest of that "language family" including Pascal and Modula-2.

It's similar in some sense to Pascal, yes (I don't really know Modula),
but from just my recollection right now, Ada is not the same as Pascal here.

>> And two "integer" types with different ranges are not the same type,
>> or even closely related, and you cannot just assign from one type to
>> another.
>
> That applies for Ada type. Not for Ada subtype and Pascal.

Maybe that is what my recollection is about. In Pascal, they are all
subtypes, while in Ada they are usually not, unless you specifically say so.

And also, enumerated types are truly types in the full sense in Ada,
which is also nice.

> But yes - it is a really really strong feature in Ada. True strict
> type check.

Yes. While it can be a headache sometimes, it do make a lot of sense.
Especially when working on larger software with lots of people involved.

>> However, if you want to interface with hardware, it becomes a little
>> messy, since then you do want to specify things in number of bits and
>> bytes. Since that's what the hardware have.
>
> It can also be a problem if the code make certain assumptions about
> when integer overflow happens.

Well, since it's Ada, you don't make any assumptions. You'll always get
exceptions on overflow, as far as I can remember. But again, in some
situation, especially when dealing with hardware, you would like to just
get what the hardware does, without Ada interfering. And then you have
to work some.

> Sure that would be ugly code. But ugly code has been seen in
> real life.

:-)

Johnny

On 2022-05-24 19:39, Simon Clubley wrote:
> On 2022-05-24, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2022-05-24 15:00, Dan Cross wrote:
>>> In article <jf2fqfFiphjU1@mid.individual.net>,
>>> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>>> On 5/23/22 16:24, Bob Eager wrote:
>>>>> On Mon, 23 May 2022 17:46:16 +0000, Simon Clubley wrote:
>>>>>
>>>>>> On 2022-05-23, Dave Froble <davef@tsoft-inc.com> wrote:
>>>>>>>
>>>>>>> What safety is there in programming when you remove the need for a
>>>>>>> programmer to exercise due diligence and careful practices?
>>>>>>>
>>>>>>>
>>>>>> With that attitude David, you should switch to using C... :-)
>>>>>
>>>>> C is for wimps. Try BCPL.
>>>>
>>>> BCPL is for wimps. Stick with Macro-11.
>>>
>>> Anything other than machine code in octal is for pikers.
>>
>> Octal? You had octal? You lucky bastards. We had to be content with binary.
>>
>> (Go ahead. Make my day. Continue this thread... :-D )
>>
>
> Lucky you! I had to be happy with using a really small magnet to
> program the core memory...
>
> Beat that!

Magnets? You had magnets? We had to wait for cosmic radiation to flip
our bits.

> Simon.
>
> PS: On a more serious note, the only time I have seen core memory is
> in a museum or in pictures. The thing that strikes me about it is
> that it was a destructive read. I can't think of anything else where
> reading it destroys the contents. Does anyone know of such technology ?

As one who still have machines at home with core memories... (they are fun)

Williams tube memory also have destructive reads.

Actually, NAND flash is also somewhat similar. It can deal with a few
reads, but have have to rewrite/refresh the data after that. So it
degrades with each read. Which, considering that it's basically like a
capacitor storing a charge, isn't that surprising.

Normal dynamic ram as well. It needs constant refreshing. But it's not
the read itself that is destructive, but time (another style of
capacitor discharge, which is more leaky).

You could argue that bubble memory reads are also destructive.

In the olden days there were lots of technologies with strange behavior.
Various delay line memories for example, where you could only access a
specific bit at certain times. Mercury memory is fun. But delay line
memory usually, similar to bubble memory, means that when the bit comes
out, if you want to retain it, it has to be rewritten again.

But right now those are the ones I can think of.

Johnny

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.

>
> 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.

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...

Chris

Den 2022-05-25 kl. 14:02, skrev chris:
> 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.
>
>>
>> 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.
>
> 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...
>
> Chris
>

Talking about DIP-switches...

My first "computer" was a project from Elector using a National
SC/MP ("Scamp") as processor. Two 8-bit switches for adress and
data (256 bytes of 8-bit shared code/data memory).

Wrote and hand loaded a program that played the intro to
"Smoke on the water"...

https://en.wikipedia.org/wiki/National_Semiconductor_SC/MP

On Wednesday, May 25, 2022 at 1:54:53 AM UTC-7, Johnny Billquist wrote:

(snip)

> Normal dynamic ram as well. It needs constant refreshing. But it's not
> the read itself that is destructive, but time (another style of
> capacitor discharge, which is more leaky).

Yes DRAM reads are also destructive. It empties the charge on the
capacitor into the sense amplifier.

Some machines with magnetic core memory do a read-modify-write
operation, without restoring the bits in between. Some early DRAM
systems did that, too. (I don't think they can do that now.)

A DRAM read cycle first reads all the bits in a row into their sense
amplifiers. Then some are selected and gated to the output.
Not so much later, the whole row is written back. A refresh
cycle does the row read and restore, but not the column select.

The separation in the timing for row access and column
access makes it convenient to use the same pins for row
addressing and column addressing, reducing the pin need.

SRAM reads are normally not destructive.

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.

>> 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. :-)

Johnny

On 2022-05-25, Johnny Billquist <bqt@softjar.se> wrote:
>
> As one who still have machines at home with core memories... (they are fun)
>
> Williams tube memory also have destructive reads.
>
> Actually, NAND flash is also somewhat similar. It can deal with a few
> reads, but have have to rewrite/refresh the data after that. So it
> degrades with each read. Which, considering that it's basically like a
> capacitor storing a charge, isn't that surprising.
>
> Normal dynamic ram as well. It needs constant refreshing. But it's not
> the read itself that is destructive, but time (another style of
> capacitor discharge, which is more leaky).
>
> You could argue that bubble memory reads are also destructive.
>
> In the olden days there were lots of technologies with strange behavior.
> Various delay line memories for example, where you could only access a
> specific bit at certain times. Mercury memory is fun. But delay line
> memory usually, similar to bubble memory, means that when the bit comes
> out, if you want to retain it, it has to be rewritten again.
>
> But right now those are the ones I can think of.
>

Well, I've just found out about a batch of technologies that were way
before my time. :-)

Thanks, Johnny. :-)

Simon.

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