Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"Don't talk to me about disclaimers! I invented disclaimers!" -- The Censored Hacker


devel / alt.lang.asm / Re: Skybuck's Universal Memory Architecture + Extension

SubjectAuthor
* Skybuck's Universal Memory Architecture + Extensionskybuck2000
`* Re: Skybuck's Universal Memory Architecture + Extensionwolfgang kern
 +* Re: Skybuck's Universal Memory Architecture + ExtensionRod Pemberton
 |`- Re: Skybuck's Universal Memory Architecture + Extensionskybuck2000
 `* Re: Skybuck's Universal Memory Architecture + Extensionskybuck2000
  `* Re: Skybuck's Universal Memory Architecture + Extensionwolfgang kern
   `- Re: Skybuck's Universal Memory Architecture + Extensionwolfgang kern

1
Skybuck's Universal Memory Architecture + Extension

<bd35a78d-c206-4739-82cb-af56bb65cf4cn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=229&group=alt.lang.asm#229

 copy link   Newsgroups: alt.lang.asm
X-Received: by 2002:a05:6214:2349:: with SMTP id hu9mr14176626qvb.93.1642314352468;
Sat, 15 Jan 2022 22:25:52 -0800 (PST)
X-Received: by 2002:a9d:6e11:: with SMTP id e17mr3164761otr.371.1642314352211;
Sat, 15 Jan 2022 22:25:52 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!2.us.feeder.erje.net!feeder.erje.net!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: alt.lang.asm
Date: Sat, 15 Jan 2022 22:25:52 -0800 (PST)
Injection-Info: google-groups.googlegroups.com; posting-host=84.25.28.171; posting-account=np6u_wkAAADxbE7UBGUIOm-csir6aX02
NNTP-Posting-Host: 84.25.28.171
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <bd35a78d-c206-4739-82cb-af56bb65cf4cn@googlegroups.com>
Subject: Skybuck's Universal Memory Architecture + Extension
From: skybuck2...@hotmail.com (skybuck2000)
Injection-Date: Sun, 16 Jan 2022 06:25:52 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 258
 by: skybuck2000 - Sun, 16 Jan 2022 06:25 UTC

Two postings, seem the second one below too:

Posting 1:

Skybuck's Universal Memory Architecture (Invention by Skybuck Flying on 18 october 2021)

The Problem:

To use Universal Fields (Universal Codes) memory needs to be able to grow.

Currently no architecture exists which allows data fields/memory fields to grow.

The Solution:

Imagine the film tron where these motor cycles draw these walls/lines the motorcyclist has to draw these walls/lines and trap the other player
by making him slam into a wall. There is also a computer game based on it called "snake", where snakes grow by eating pixels. As the snake grows
it describes a line, the snake is free to move left, right, up, down but may not end up on a square already taken by any other snake.

Imagine storing a data bit on each square as the snake grows.

These lines/walls that are formed by the snake/motor cyclist can be considered a "data tape".
Alan Turning described the need for an imaginary data tape of endless length to be able to do "universal computing" and "universal machines".

To be able to know where the snake originated, the start of data tape has to be recorded. This would be a 2D or 3D or ND coordinate.

For example SnakeSourceX,SnakeSourceY this would be the tail of the snake, which can also be described as SnakeTailX,SnakeTailY

To be able to know where the head of the snake is so it can be made to grow, the end of the data tape has to be recorded.

For example SnakeDestX,SnakeDestY this would be the head of the snake, which can also be described as SnakeHeadX,SneakHeadY.

A processor could number the snakes and refer to them by numbers, basically each snake is a data field.

To encode instructions for the processor, the instructions codify on which snake/data field the instruction operates.

To store these data fields there could be an additional memory structure which stores these snake coordinates as follows:

SnakeReferenceMemoryStructure:

SnakeNumber, SnakeSourceX, SnakeSourceY, SnakeDestX, SnakeDestY

For example:
0, 100, 500, 40, 30
1, 10, 20, 100, 200
2, 60, 70, 30, 40
3, 101, 302, 35, 67
4, 56, 75, 45, 34

The processor can then refer to data fields by SnakeNumber, so that instructions stay consist and entire snakes can be moved around in memory in case a snake crashes
into a wall.

To store data bits into the snake each memory cell/unit has to have the following properties:

DataBit On/Off (1 transistor)
DirectionBit0 On/Off (1 transistor)
DirectionBit1 On/Off (1 transistor)
ConnectedBit On/Off (1 transistor) (optional)

Each 2D memory cell therefore consists out of these 4 transistors.

The data bit transistor records the information data bit 0 or 1.

The DirectionBit0 and DirectionBit1 describe in which direction the snake grew and therefore to which other memory cell the current memory cell is "connected".
DirectionBit0, DirectionBit1
00 = up
01 = right
10 = down
11 = left

The connected bit is optional, based on universal codes the software itself could decide if another snake cell follows the last read snake cell, however for allocation
purposes/algorithms it may be usefull to codify this information directly into the memory units and thus ConnectedBit describes if any cell follows the current one.

ConnectedBit
0 = head of snake/last cell
1 = intermediate cell

The challenge for the computer systems and memory manager is to allocate snakes as efficiently as possible, basically to play the game snakes as efficiently as possible.
Algorithms could be developed or perhaps already exist that excell in this. Different allocations, direction strategies and starting points could be tried.

In the event that a snake/data tape crashes into a wall, can no longer grow an "exception" like mechanism is thrown.

The processor or memory manager which is responsible for the growing of data tapes/snakes throws an exception like event:

Describing which snake crashed, plus optionally source and dest information for quick reference or it can be looked up later in the snake memory reference structure by
snake number.

Event generated:
Snake X crashed

Or more advanced event:
Snake X, SnakeSourceX,SnakeSourceY,SnakeDestX,SnakeDestY crashed.

however to make sure the information is consistent perhaps it's better to consult the snake memory reference in the event handler to be sure, perhaps
this would make programmers of such event handlers feel more at ease that they have the correct/most recent information, it is more of an emotional
consideration, but could also prevent race conditions/race information in case maybe something else modified it in between the event generation and event handler.
Preferably none of the snake information/structures/data is changed in between event firing and event handling.

A computer instruction could be encoded as follows, just an example:

Operation Codes
No Operation = 0
Copy = 1
Addition = 2
Subtraction = 3
Multiply = 4
Division = 5
Jump = 6

Addressing Modes
0 = constants
1 = direct addressing
2 = indirect addressing

Instructions:
Operation Code, Source Addressing Mode, Source Data Field, Dest Addressing Mode, Dest Data Field

The following pascal pseudo code will be translated into instructions below:

var
Counter : TDataField;
Value : TDataField;

begin
Counter := 0;
Value := 5;

while true do
begin
Counter := Counter + Value;
end;

end;

Compiler outputs:

Counter = data field 0
Value = data field 1

Assembly instructions:

// copy constant 0 to data field 0
copy, 0, 0, 1, 0

// copy constant 5 to data field 1
copy, 5, 0, 1, 1

// add value to counter
add, 1, 1, 1, 0

// jump to previous instruction
jump -1

Hardware wise each "memory unit" must be readable, writeable and addressable. Each memory unit contains 4 transistors as described above.

I imagine a grid of memory units each with 4 transistors. Each memory unit is connected to a memory bus and address busses, one address bus for each coordinate/dimension.

To manipulate a memory unit the hardware has to be able to do the following:

put coordinate x on the x bus.
put coordinate y on the y bus.
read/write the transistors, this would imply a 4 data bit bus, or just a 1 data bit bus and each transistor is read in sequence.

A more complex memory unit could be constructed so that a processor only read/write 1 bit at a time, like a pci express lane, software is responsible for
decoding the communication.

A benefit of this could be less wires on motherboards, and more placement of individual memory chips, possibly for multi-core/many-core scenerios where each
core has access to it's own memory, or possibly access to multiple memory units.

The idea here is to also spread heat across a large surface area/multiple chips, also to allow more cooling solutions to be placed on these chips.

Further inspiration was derived from the movie Chappie, the game worms, vectorization algorithms, vga pixel graphics bouncing like water of of logos, intersections/intersection map,
Alan Turing's imaginary ticker/data tape, redcode/corewars.

Bye for now,
Skybuck Flying ! =D

P.S.: Also see my other inventions such a Skybuck's Universal Code, Skybuck's Universal Data Structure

Posting 2:

Skybuck's Universal Memory Architecture Extension (16 january 2022)

There may be a problem with the Tron/Snake based approach/idea.

In Tron/Snake the motor cycles/snakes can only grow. Shrinking is not possible, except when they die.

To allow shrinking additional information would need to be recorded. For example where the snake cell came from.

To incorporate this functionality the following changes should be made:

DirectionBit0 is renamed to GrowDirectionBit0
DirectionBit1 is renamed to GrowDirectionBit1

Two new direction bits are added:

ShrinkDirectionBit0
ShrinkDirectionBit1

The meaning of combining two of the same direction bits to form a direction bit field remain the same:

Order of DirectionBits: DirectionBit0, DirectionBit1:
00 = up
01 = right
10 = down
11 = left

(DirectionBit0 is LSB=least significant bit, DirectionBit1 is MSB=Most Significant Bit)

The ShrinkDirectionBits should be set to where the snake cell came from, it's ancestor/predecessor.

So for example.

If the current snake cell is on x 200 y 100 and it came from x 199 y 100 the shrink bits would be set as follows:

ShrinkDirectionBit0 = 1
ShrinkDirectionBit1 = 1

This indicates that if the snake wants to shrink back into a safe memory cell that was allocated before the growth then it can do so
and go there.

This leaves one problem remaining indicating if there was a previous connected bit. Like in the ConnectionBit description.

This may and could also be updated or the head/tail pointers could be used to detect if it's already at the head/tail.
Or as defined as SourceX,SourceY.

If the connection bit feature is implemented/used it will also need to be updated and renamed:

ConnectionBit will be renamed to NextBitConnected

and a new bit will be introduced:

PreviousBitConnected

The maining of these bits are slightly altered:

For NextBitConnected it means:

0 = head of snake/last cell
1 = intermediate cell


Click here to read the complete article
Re: Skybuck's Universal Memory Architecture + Extension

<ss0gnj$1otq$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=230&group=alt.lang.asm#230

 copy link   Newsgroups: alt.lang.asm
Path: i2pn2.org!i2pn.org!aioe.org!UPYjgp84z/VV+HPErJ48Mw.user.46.165.242.75.POSTED!not-for-mail
From: nowh...@nevernet.at (wolfgang kern)
Newsgroups: alt.lang.asm
Subject: Re: Skybuck's Universal Memory Architecture + Extension
Date: Sun, 16 Jan 2022 08:16:02 +0100
Organization: Aioe.org NNTP Server
Message-ID: <ss0gnj$1otq$1@gioia.aioe.org>
References: <bd35a78d-c206-4739-82cb-af56bb65cf4cn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="58298"; posting-host="UPYjgp84z/VV+HPErJ48Mw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.1.2
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-US
 by: wolfgang kern - Sun, 16 Jan 2022 07:16 UTC

On 16/01/2022 07:25, skybuck2000 wrote:
> Two postings, seem the second one below too:
[snip]
you reinvented whats already standard since 30 years.
just read any GPU manual and look at the instructions.
__
wolfgang

Re: Skybuck's Universal Memory Architecture + Extension

<ss3ids$f13$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=231&group=alt.lang.asm#231

 copy link   Newsgroups: alt.lang.asm
Path: i2pn2.org!i2pn.org!aioe.org!JKehOyGOGgs2f2NKLRXdGg.user.46.165.242.75.POSTED!not-for-mail
From: noem...@basdxcqvbe.com (Rod Pemberton)
Newsgroups: alt.lang.asm
Subject: Re: Skybuck's Universal Memory Architecture + Extension
Date: Mon, 17 Jan 2022 06:05:03 -0500
Organization: Aioe.org NNTP Server
Message-ID: <ss3ids$f13$1@gioia.aioe.org>
References: <bd35a78d-c206-4739-82cb-af56bb65cf4cn@googlegroups.com>
<ss0gnj$1otq$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="15395"; posting-host="JKehOyGOGgs2f2NKLRXdGg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
X-Notice: Filtered by postfilter v. 0.9.2
 by: Rod Pemberton - Mon, 17 Jan 2022 11:05 UTC

On Sun, 16 Jan 2022 08:16:02 +0100
wolfgang kern <nowhere@nevernet.at> wrote:

> On 16/01/2022 07:25, skybuck2000 wrote:

> > Two postings, seem the second one below too:
> [snip]
> you reinvented whats already standard since 30 years.
> just read any GPU manual and look at the instructions.

At what point does humanity give up on developing new microprocessor
instruction sets? ...

We have a phrase in English, "Reinventing the wheel."

--
Once a President becomes a permanent failure, he then becomes a
fearmonger.

Re: Skybuck's Universal Memory Architecture + Extension

<b6a6508d-b31f-4ad2-b249-6ee3e22277a3n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=236&group=alt.lang.asm#236

 copy link   Newsgroups: alt.lang.asm
X-Received: by 2002:ac8:7d0e:: with SMTP id g14mr22403108qtb.638.1642542913322;
Tue, 18 Jan 2022 13:55:13 -0800 (PST)
X-Received: by 2002:aca:1204:: with SMTP id 4mr457162ois.85.1642542913018;
Tue, 18 Jan 2022 13:55:13 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: alt.lang.asm
Date: Tue, 18 Jan 2022 13:55:12 -0800 (PST)
In-Reply-To: <ss0gnj$1otq$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=84.25.28.171; posting-account=np6u_wkAAADxbE7UBGUIOm-csir6aX02
NNTP-Posting-Host: 84.25.28.171
References: <bd35a78d-c206-4739-82cb-af56bb65cf4cn@googlegroups.com> <ss0gnj$1otq$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b6a6508d-b31f-4ad2-b249-6ee3e22277a3n@googlegroups.com>
Subject: Re: Skybuck's Universal Memory Architecture + Extension
From: skybuck2...@hotmail.com (skybuck2000)
Injection-Date: Tue, 18 Jan 2022 21:55:13 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 20
 by: skybuck2000 - Tue, 18 Jan 2022 21:55 UTC

On Sunday, January 16, 2022 at 8:16:05 AM UTC+1, wolfgang kern wrote:
> On 16/01/2022 07:25, skybuck2000 wrote:
> > Two postings, seem the second one below too:
> [snip]
> you reinvented whats already standard since 30 years.
> just read any GPU manual and look at the instructions.

Nope, read it again, and again, until you get it and don't be jealous ! LOL.

All current instruction sets I have ever seen have the same flaw:

One or Two complement's.

Leading to overflows and underflows.

With my new tech this should be a thing of the past :P*

Enjoy your shittty lang.asm ! LOL it needs updating with sky-tech ! =D

Bye, Bye,
Skybuck.

Re: Skybuck's Universal Memory Architecture + Extension

<72d660fb-c381-43c5-95a5-beceb86d421bn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=237&group=alt.lang.asm#237

 copy link   Newsgroups: alt.lang.asm
X-Received: by 2002:a05:620a:4489:: with SMTP id x9mr2893640qkp.633.1642542972660;
Tue, 18 Jan 2022 13:56:12 -0800 (PST)
X-Received: by 2002:aca:62d7:: with SMTP id w206mr494785oib.90.1642542972279;
Tue, 18 Jan 2022 13:56:12 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: alt.lang.asm
Date: Tue, 18 Jan 2022 13:56:12 -0800 (PST)
In-Reply-To: <ss3ids$f13$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=84.25.28.171; posting-account=np6u_wkAAADxbE7UBGUIOm-csir6aX02
NNTP-Posting-Host: 84.25.28.171
References: <bd35a78d-c206-4739-82cb-af56bb65cf4cn@googlegroups.com>
<ss0gnj$1otq$1@gioia.aioe.org> <ss3ids$f13$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <72d660fb-c381-43c5-95a5-beceb86d421bn@googlegroups.com>
Subject: Re: Skybuck's Universal Memory Architecture + Extension
From: skybuck2...@hotmail.com (skybuck2000)
Injection-Date: Tue, 18 Jan 2022 21:56:12 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 28
 by: skybuck2000 - Tue, 18 Jan 2022 21:56 UTC

On Monday, January 17, 2022 at 12:03:27 PM UTC+1, Rod Pemberton wrote:
> On Sun, 16 Jan 2022 08:16:02 +0100
> wolfgang kern <now...@nevernet.at> wrote:
>
> > On 16/01/2022 07:25, skybuck2000 wrote:
>
> > > Two postings, seem the second one below too:
> > [snip]
> > you reinvented whats already standard since 30 years.
> > just read any GPU manual and look at the instructions.
> At what point does humanity give up on developing new microprocessor
> instruction sets? ...
>
> We have a phrase in English, "Reinventing the wheel."

Until it invents a decent one.

Everything currently invented is SHIT.

See two complement problem.

As long as your instruction set can produce overflows it's flawed lol.

Unless it manages to overflow the universe ! HAHAHA.

32 Bits ?! My dick is bigger than that ! LOL.

Bye,
Skybuck.

Re: Skybuck's Universal Memory Architecture + Extension

<ss86ba$ana$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=238&group=alt.lang.asm#238

 copy link   Newsgroups: alt.lang.asm
Path: i2pn2.org!i2pn.org!aioe.org!F9g4l4xAjkimNZTIiS2c2g.user.46.165.242.75.POSTED!not-for-mail
From: nowh...@nevernet.at (wolfgang kern)
Newsgroups: alt.lang.asm
Subject: Re: Skybuck's Universal Memory Architecture + Extension
Date: Wed, 19 Jan 2022 06:07:51 +0100
Organization: Aioe.org NNTP Server
Message-ID: <ss86ba$ana$1@gioia.aioe.org>
References: <bd35a78d-c206-4739-82cb-af56bb65cf4cn@googlegroups.com>
<ss0gnj$1otq$1@gioia.aioe.org>
<b6a6508d-b31f-4ad2-b249-6ee3e22277a3n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="10986"; posting-host="F9g4l4xAjkimNZTIiS2c2g.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.1.2
Content-Language: en-US
X-Notice: Filtered by postfilter v. 0.9.2
 by: wolfgang kern - Wed, 19 Jan 2022 05:07 UTC

On 18/01/2022 22:55, skybuck2000 wrote:
> On Sunday, January 16, 2022 at 8:16:05 AM UTC+1, wolfgang kern wrote:
>> On 16/01/2022 07:25, skybuck2000 wrote:
>>> Two postings, seem the second one below too:
>> [snip]
>> you reinvented whats already standard since 30 years.
>> just read any GPU manual and look at the instructions.
>
> Nope, read it again, and again, until you get it and don't be jealous ! LOL.
>
> All current instruction sets I have ever seen have the same flaw:
>
> One or Two complement's.
>
> Leading to overflows and underflows.
>
> With my new tech this should be a thing of the past :P*
>
> Enjoy your shittty lang.asm ! LOL it needs updating with sky-tech ! =D

I wont join your flying device [bucket].

you obvious never heard nor read about hardware saturation,
these feature allow either clamping or truncation w/o overflow.

Overflow and Off by One are HLL-issues, blame C and stupid programmers.

I use much better than ASM or HLL: hexadecimal on bare metal,
where it's easy to avoid such, IOW it never will happen here.

and GPU clamping instructions exists since the very start.
__
wolfgang

Re: Skybuck's Universal Memory Architecture + Extension

<ssnh4f$s56$1@gioia.aioe.org>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=239&group=alt.lang.asm#239

 copy link   Newsgroups: alt.lang.asm
Path: i2pn2.org!i2pn.org!aioe.org!/jOWTAgcE+UixVeQhHF5qw.user.46.165.242.75.POSTED!not-for-mail
From: nowh...@nevernet.at (wolfgang kern)
Newsgroups: alt.lang.asm
Subject: Re: Skybuck's Universal Memory Architecture + Extension
Date: Tue, 25 Jan 2022 01:43:58 +0100
Organization: Aioe.org NNTP Server
Message-ID: <ssnh4f$s56$1@gioia.aioe.org>
References: <bd35a78d-c206-4739-82cb-af56bb65cf4cn@googlegroups.com>
<ss0gnj$1otq$1@gioia.aioe.org>
<b6a6508d-b31f-4ad2-b249-6ee3e22277a3n@googlegroups.com>
<ss86ba$ana$1@gioia.aioe.org>
<6f6977e9-26c4-44b3-b0fa-a0f6d1496b12n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="28838"; posting-host="/jOWTAgcE+UixVeQhHF5qw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.1.2
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-US
 by: wolfgang kern - Tue, 25 Jan 2022 00:43 UTC

On 24/01/2022 15:52, skybuck2000 wrote:
....
>>> One or Two complement's.
>>> Leading to overflows and underflows.
....
> Subtraction and Addition is a serious problem in two complement.
> Many combination will overflow and underflow and there is nothing you can do about it.

I see where your problem come from :)
now guess why there are CF,SF,ZF and OF in the flag register.
they are designed to either tell error or select rounding mode.

easiest thing to avoid overflow exceptions is to check up front.

for my OS I wrote a tiny scientific calculator which can
ADD,SUB.MUL,DIV,MOD,TRIG.. until MULADD and FAC also mixed
for all my supported numeric variables starting from any size
(in nibbles) up to 512 bit, all unsigned, signed or mixed.

it is pure software and does not use hardware features, but
the result buffers are always double sized, so max=1024 bit.

few things that could overflow are chain action like FAC(n)
and MULADD, but a limit check up front easy avoids overflow.

the problem with HLL might just be that it defaults to signed
while x86 legacy CPUs don't know signed and just use the wrap
around limits to work as if signed (two's complement advantage).
__
wolfgang

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor