Quadibloc <jsavard@ecn.ab.ca> schrieb:
> On Monday, October 2, 2023 at 7:51:53 AM UTC-6, Thomas Koenig wrote:
>
>> What languages would support this?
>>
>> The only language which has the method of accessing floating point
>> and integer types based on needed accuracy that I know is Fortran.
>> Putting this into C or C++ would be a major headache, to put it mildly.
>
> I wasn't thinking in terms of using novel features of the latest Fortran standard
> that allow types to be specified by length, after the manner pioneered by Ada.
>
> Instead, what I was thinking of would work perfectly well even with languages
> like C. If in one C compiler, int is 16 bits, and long is 32 bits, and in another int
> is 32 bits, and long is 64 bits... what is to stop a third compiler from having int as
> 24 bits and long as 48 bits, and a fourth compiler from having int as 36 bits
> and long as 72 bits?

Compatibility nightmares?

Quadibloc <jsavard@ecn.ab.ca> writes:
>On Monday, October 2, 2023 at 7:51:53=E2=80=AFAM UTC-6, Thomas Koenig wrote=
>:
>
>> What languages would support this?=20
>>=20
>> The only language which has the method of accessing floating point=20
>> and integer types based on needed accuracy that I know is Fortran.=20
>> Putting this into C or C++ would be a major headache, to put it mildly.
>
>I wasn't thinking in terms of using novel features of the latest Fortran s=
>tandard
>that allow types to be specified by length, after the manner pioneered by A=
>da.

It was not pioneered by ADA. Burroughs systems allowed specification
of accuracy (leaving aside COBOL PIC clauses, which of course predate ADA)
in the utility language BPL (circa 1966):

INTEGER age(3); & Declares a 3-digit variable named age

and the language SPRITE (circa 1977) (used to write the MCP):

VAR
usernumber 0..999999, % allocates 6 digits
groupnumber 0..99, % allocates 2 digits
returnval -1..33; % allocates 3 digits (2 plus sign digit).

In article <322d119a-6fd3-43dc-a78b-a0255e3bea75n@googlegroups.com>,
jsavard@ecn.ab.ca (Quadibloc) wrote:

> Instead, what I was thinking of would work perfectly well even with
> languages like C. If in one C compiler, int is 16 bits, and long is
> 32 bits, and in another int is 32 bits, and long is 64 bits... what
> is to stop a third compiler from having int as 24 bits and long as
> 48 bits, and a fourth compiler from having int as 36 bits and long
> as 72 bits?
>
> With the floating-point types undergoing the analogous
> transformation.

C can accommodate all of these, of course.

> A command-line switch, of course, would allow a single compiler to
> generate code using any one of the possible sizes of data memory.

Do you envisage this architecture supporting calling between different
bit-lengths, and conversion of pointers between them? It seems incomplete
without that.

John

On Monday, October 2, 2023 at 4:22:21 PM UTC-6, John Dallman wrote:

> Do you envisage this architecture supporting calling between different
> bit-lengths, and conversion of pointers between them? It seems incomplete
> without that.

Calling, yes; conversion of pointers, no.

Essentially, memory could be allocated as either 64-bit wide, 48-bit-wide,
60-bit wide, or 36-bit wide. It would be possible to access 40-bit wide data
within the 64-bit wide area using its own native byte pointers, and within
the 60-bit wide area using converted pointers. 64-bit wide data would actually
be within 48-bit wide memory, with converted pointers.

But except for those specific pointer conversions, which basically change the
type of the memory to which they apply, other conversions would not exist.

But code could reference memory of all the possible widths. There would be
separate register-to-register arithmetic instructions for each data type; memory-reference
instructions would be modified depending on the kind of memory they are addressing.

So a given area of physical memory could be allocated as 36-bit wide or 60-bit wide
or whatever - and what it woiuld be allocated _to_ is a virtual address within a single
continuous address space.

So if an address happens to point to a 9-bit byte in 36-bit-wide memory, a 12-bit slab in
48-bit wide memory, or an 8-bit byte in 64-bit wide memory, that would determine what
bits of a floating-point register would be loaded by a load double precision instruction.

John Savard

On Monday, October 2, 2023 at 7:43:24 AM UTC-6, MitchAlsup wrote:
> On Monday, October 2, 2023 at 1:42:57 AM UTC-5, Quadibloc wrote:

> > So capabilities that address niche applications, such as simulating old
> > architectures for retrocomputing, are included in the very wide area of
> > things that should be supported by... the only available processor.

> Market share = DIV 10,000.........

> > Or, if there's a handful of different ISAs, but they mostly look alike, there
> > should be at least one processor available with that kind of flexibility.

> Is there enough money in that niché to pay for the design team, let alone
> manufacturing, management, and profit ??

At this stage, I'm not too worried about such considerations.

Of course, one possible design win would be selling a modified version of
this chip to Unisys, which they could use to power their Clear Path Dorado
mainfames more efficiently than the Intel processors they're now using.

John Savard

On Monday, October 2, 2023 at 4:41:15 PM UTC-6, Quadibloc wrote:
> On Monday, October 2, 2023 at 4:22:21 PM UTC-6, John Dallman wrote:

> > Do you envisage this architecture supporting calling between different
> > bit-lengths, and conversion of pointers between them? It seems incomplete
> > without that.

> Calling, yes;

To clarify: except when emulation is taking place, all executable code would be
stored only in 64-bit memory. Calling would be possible between procedures in
64-bit memory which use data memory of different widths.

John Savard

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> On Monday, October 2, 2023 at 4:22:21 PM UTC-6, John Dallman wrote:
>
>> Do you envisage this architecture supporting calling between different
>> bit-lengths, and conversion of pointers between them? It seems incomplete
>> without that.
>
> Calling, yes; conversion of pointers, no.
>
> Essentially, memory could be allocated as either 64-bit wide, 48-bit-wide,
> 60-bit wide, or 36-bit wide. It would be possible to access 40-bit wide data
> within the 64-bit wide area using its own native byte pointers, and within
> the 60-bit wide area using converted pointers. 64-bit wide data would actually
> be within 48-bit wide memory, with converted pointers.

This would be hideously complex.

If you want to go that route, just allow nibble addressing and
misaligned addresses. However, just tossing the data sizes not
divislbe by eight sounds like a better idea, because otherwise
you'll ran run afoul of C's rule that a char* can address anything.

Or is memcpy() not supposed to work on your architecture?

On Tuesday, October 3, 2023 at 6:15:57 AM UTC-4, Thomas Koenig wrote:
> Quadibloc <jsa...@ecn.ab.ca> schrieb:
> > On Monday, October 2, 2023 at 4:22:21 PM UTC-6, John Dallman wrote:
> >
> >> Do you envisage this architecture supporting calling between different
> >> bit-lengths, and conversion of pointers between them? It seems incomplete
> >> without that.
> >
> > Calling, yes; conversion of pointers, no.
> >
> > Essentially, memory could be allocated as either 64-bit wide, 48-bit-wide,
> > 60-bit wide, or 36-bit wide. It would be possible to access 40-bit wide data
> > within the 64-bit wide area using its own native byte pointers, and within
> > the 60-bit wide area using converted pointers. 64-bit wide data would actually
> > be within 48-bit wide memory, with converted pointers.
> This would be hideously complex.
>
> If you want to go that route, just allow nibble addressing and
> misaligned addresses. However, just tossing the data sizes not
> divislbe by eight sounds like a better idea, because otherwise
> you'll ran run afoul of C's rule that a char* can address anything.
>
> Or is memcpy() not supposed to work on your architecture?

OT: Is anyone else seeing the group spammed with messages, I think in Korean?

robf...@gmail.com <robfi680@gmail.com> schrieb:

> OT: Is anyone else seeing the group spammed with messages, I think in Korean?

Google groups shows them, but fortunately they do not reach the news
server I use.

On 03/10/2023 13:40, robf...@gmail.com wrote:
> On Tuesday, October 3, 2023 at 6:15:57 AM UTC-4, Thomas Koenig wrote:
>> Quadibloc <jsa...@ecn.ab.ca> schrieb:
>>> On Monday, October 2, 2023 at 4:22:21 PM UTC-6, John Dallman wrote:
>>>
>>>> Do you envisage this architecture supporting calling between different
>>>> bit-lengths, and conversion of pointers between them? It seems incomplete
>>>> without that.
>>>
>>> Calling, yes; conversion of pointers, no.
>>>
>>> Essentially, memory could be allocated as either 64-bit wide, 48-bit-wide,
>>> 60-bit wide, or 36-bit wide. It would be possible to access 40-bit wide data
>>> within the 64-bit wide area using its own native byte pointers, and within
>>> the 60-bit wide area using converted pointers. 64-bit wide data would actually
>>> be within 48-bit wide memory, with converted pointers.
>> This would be hideously complex.
>>
>> If you want to go that route, just allow nibble addressing and
>> misaligned addresses. However, just tossing the data sizes not
>> divislbe by eight sounds like a better idea, because otherwise
>> you'll ran run afoul of C's rule that a char* can address anything.
>>
>> Or is memcpy() not supposed to work on your architecture?
>
> OT: Is anyone else seeing the group spammed with messages, I think in Korean?
>

I have heard it's Thai, but I am not sure - it's certainly not Korean.
It comes through Google's spam generators. I expect it will last for a
bit, then disappear - making google accounts for spam posting is cheap,
but not entirely free, and they'll soon move elsewhere.

Some Usenet servers are better than others at blocking the spam before
the user sees it, but its certainly visible in news.eternal-september.org.

Thomas Koenig wrote:
> robf...@gmail.com <robfi680@gmail.com> schrieb:
>
>> OT: Is anyone else seeing the group spammed with messages, I think in Korean?
>
> Google groups shows them, but fortunately they do not reach the news
> server I use.

They are reaching here too, hundreds per day.
The usenet message headers indicate its coming from google groups.

The links go to the website www.ufascrr.com which says it is
sports betting and online casinos. The html language is "th" = Thai.

The Whois on that site says it is registered in Toronto but it
cannot be a Toronto company because gambling is regulated here
to the Ontario government.

https://www.whois.com/whois/ufascrr.com

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Sunday, October 1, 2023 at 3:50:43 PM UTC-5, Thomas Koenig wrote:
>> Quadibloc <jsa...@ecn.ab.ca> schrieb:
>> > On Saturday, September 30, 2023 at 3:02:44 AM UTC-6, Quadibloc wrote:
>> >> > On Monday, September 25, 2023 at 4:40:46 AM UTC-6, Quadibloc wrote:
>> >>
>> >> > > http://www.quadibloc.com/arch/per04.htm
>> >
>> >> Divide-by-21 for 36 bits, and divide-by-25 for 60 bits. However, these are
>> >> still achievable simply, because three is 11 in binary, seven is 111 in binary,
>> >> and fifteen, a multiple of five, is 1111 in binary - so the end-around-carry
>> >> design for a simple and fast division circuit is applicable, even though in
>> >> both cases two have to be cascaded.
>> >
>> > Now I have proposed further tweaks.
>> >
>> > Just use divide-by-three addressing, not the butterfly technique, for
>> > handling the 64-bit word.
>> >
>> > Use divide-by-85 for 36 bits, and divide-by-51 for 60 bits,
>> How much delay would this include?
><
> There is a reason nobody repeats the BSP memory addressing style.
><
>> > which still only
>> > require a two-step cascade of simple division units,
>> "simple"?
><
> This is one place where theory diverges from practice.
>>
>> Actually, if you want to do this modulo 85, a single step would
>> suffice, because 256 ≡ 1 (mod 85).
>>
>> Add together all bytes of your address, add whatever exceeds
>> eight bits to the number you get, shifted by eight bits, and use
>> a look-up-table or random logic or a NOR plane to calculate the
>> remainder of division by 85.
><
> My bet is that is you alter the base unit to 85×2^n that you can
> find a different constant doing the same thing with quite a bit less
> logic. {Left as a problem for the desirous student.}

Hm, not sure what this would be. Addresses in user programs
need to be contiguous, and if somebody wants to use 85 memory
banks, then this seems like the obvious way to go about this.

>>
>> Then subtract the remainder from the original value and multiply
>> the result with the multiplicative inverse of 85 modulo 2^n
>> (18229723555195321597 or 0xFCFCFCFCFCFCFCFD for 64 bits, if you're
>> interested).
>>
>> Other people may know better than me, but the first addition sounds
>> like one cycle, done with a carry-save adder.
><
> Given you know "85" and can get the multiplier tree booth recoded and
> setup; yes, this is 1 cycle, without that given it already overflows 1 cycle.

For the multiplicative inverse:

0xFCFCFCFCFCFCFCFD = 0x10101010101010101 - 0x404040404040404, the
high bit of 0x10101010101010101 is not needed, so this would be
a carry-save adder with 8 additions and 8 subtractions, hard-wired.

Does this sound more like two or like three cylces?

On Tuesday, October 3, 2023 at 6:50:10 AM UTC-6, David Brown wrote:

> I have heard it's Thai, but I am not sure - it's certainly not Korean.

Yes, it certainly looks like Thai to me.

John Savard

On Tuesday, October 3, 2023 at 4:15:57 AM UTC-6, Thomas Koenig wrote:

> Or is memcpy() not supposed to work on your architecture?

One can only copy data from memory to memory within memory of the
same type.
The ISA is envisaged as having a 64-bit word subset - these variable
sizes of memory, with the register-to-register instructions for the additional
lengths of data can be added on in a modified version of a conventional
ISA as an extra feature.
So there would be a C compiler for the 8-bit only version, and then modified
and specialized tools to allow programs to be written which can make use of
all the memory widths.
For memory widths other than 64 bits, the architecture becomes Harvard
instead of von Neumann - as noted, unless emulation is taking place, all
code is in 64-bit memory.

Now, though, obviously there will have to be a way to read data from files
directly to memory of different widths. Perhaps memory-to-memory copy
instructions between widths will be needed, rather than making I/O more
complicated.

John Savard

On 03/10/2023 19:49, Quadibloc wrote:
> On Tuesday, October 3, 2023 at 6:50:10 AM UTC-6, David Brown wrote:
>
>> I have heard it's Thai, but I am not sure - it's certainly not Korean.
>
> Yes, it certainly looks like Thai to me.

It is Thai. And it's currently flooding a lot of different newsgroups.
I'm wondering what purpose it serves other than trying to ruin the rests
of Usenet, as the number of people actually speaking Thai in these
newsgroups is probably close to zero.

Note for gnus users: Keith Thompson over in comp.lang.c posted an
excerpt of his score file which deals with the problem (several other
users have posted solutions for other news readers). His version
only looks for Thai characters in the From field; here's my version
which builds upon his but also looks for them in the Subject field.

In $HOME/News/comp.arch.SCORE, put

(("from"
("Skybuck Flying <skybuckflying@gmail.com>" -1000 nil e)
... other lines to remove ...
("\"Skybuck Flying\" <spam@hotmail.com>" -1000 nil e)
("[ก-๛]" -2000 nil r))
("subject"
("[ก-๛]" -2000 nil r))
(expunge -1001))

The relevant rule is the last one in each section. They set the score
for anything with at least one Thai character to -2000; then the expunge
line deletes everything with a score of -1001 or below so the posts just
vanish.

I find it amusing that dear Skybuck appears as both the first and last
entry in my "from" match list, under different email addresses (he also
appears several other places in the list). His score, as well as a host
of others, is only -1000 so I do see that their posts exist but they
show as if I'd already read them. For ordinary levels of annoyance
that's adequate; this Thai spam is whole new levels of obnoxious.

On Tue, 03 Oct 2023 13:34:11 -0600, Joe Pfeiffer
<pfeiffer@cs.nmsu.edu> wrote:

>Note for gnus users: Keith Thompson over in comp.lang.c posted an
>excerpt of his score file which deals with the problem (several other
>users have posted solutions for other news readers). His version
>only looks for Thai characters in the From field; here's my version
>which builds upon his but also looks for them in the Subject field.
>
>In $HOME/News/comp.arch.SCORE, put
>
>(("from"
> ("Skybuck Flying <skybuckflying@gmail.com>" -1000 nil e)
> ... other lines to remove ...
> ("\"Skybuck Flying\" <spam@hotmail.com>" -1000 nil e)
> ("[?-?]" -2000 nil r))
> ("subject"
> ("[?-?]" -2000 nil r))
> (expunge -1001))
>
>The relevant rule is the last one in each section. They set the score
>for anything with at least one Thai character to -2000; then the expunge
>line deletes everything with a score of -1001 or below so the posts just
>vanish.
>
>I find it amusing that dear Skybuck appears as both the first and last
>entry in my "from" match list, under different email addresses (he also
>appears several other places in the list). His score, as well as a host
>of others, is only -1000 so I do see that their posts exist but they
>show as if I'd already read them. For ordinary levels of annoyance
>that's adequate; this Thai spam is whole new levels of obnoxious.

Yeah ... my reader filters most of it: unfortunately the filter
doesn't work on body text so I can't filter on the easily recognizable
websites. Nor can I easily specify Thai characters - I can only match
on the small amount of ASCII in the subjects ... so some of it does
get through.

Pop to the top

On Monday, September 11, 2023 at 11:32:41 PM UTC-6, Quadibloc wrote:
> After trying to work out all kinds of bizarre ways to make a computer
> that uses a 12-bit basic unit of memory work efficiently with
> single-precision floats that are 36 bits long, and double-precision
> floats that are 60 bits long, I've decided it's time to throw in the towel
> on that one, and achieve my goals in another way.
>
> http://www.quadibloc.com/arch/per15.htm

Somehow, I managed to forget to upload three of the images for this
page. That has now, finally, been corrected now that I've noticed it.

John Savard