Skybuck's Universal Memory Architecture

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

Skysuck strikes again...

-- 
skybuck2000 <skybuck2000@hotmail.com> wrote:

> X-Received: by 2002:a05:6214:2307:: with SMTP id gc7mr27799363qvb.34.1634590982981;        Mon, 18 Oct 2021 14:03:02 -0700 (PDT)
> X-Received: by 2002:a25:3104:: with SMTP id x4mr31788765ybx.512.1634590982742; Mon, 18 Oct 2021 14:03:02 -0700 (PDT)
> Path: eternal-september.org!reader02.eternal-september.org!news.mixmin.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
> Newsgroups: sci.electronics.design
> Date: Mon, 18 Oct 2021 14:03:02 -0700 (PDT)
> 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: <66879f56-52f1-4df4-8663-4703fd9c0e3fn@googlegroups.com>
> Subject: Skybuck's Universal Memory Architecture
> From: skybuck2000 <skybuck2000@hotmail.com>
> Injection-Date: Mon, 18 Oct 2021 21:03:02 +0000
> Content-Type: text/plain; charset="UTF-8"
> Xref: reader02.eternal-september.org sci.electronics.design:649636
> 
> 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 excess 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
> 
> 

The John Doe troll stated the following in message-id 
<sdhn7c$pkp$4@dont-email.me>:

> The troll doesn't even know how to format a USENET post...

And the John Doe troll stated the following in message-id 
<sg3kr7$qt5$1@dont-email.me>:

> The reason Bozo cannot figure out how to get Google to keep from 
> breaking its lines in inappropriate places is because Bozo is 
> CLUELESS...

And yet, the clueless John Doe troll has itself posted yet another
incorrectly formatted USENET posting on Mon, 18 Oct 2021 23:03:27 -0000
(UTC) in message-id <skkufv$fq7$7@dont-email.me>.

7xvG+FXvOfJs

A nym-shifting stalker, usually "Corvid" also "Charger Boy".
Was spanked hard in (sci.electronics.repair)...

see also...
=?UTF-8?Q?C=c3=b6rvid?= <bl@ckbirds.org>
=?UTF-8?B?8J+QriBDb3dzIGFyZSBOaWNlIPCfkK4=?= <nice@cows.moo>
Banders <snap@mailchute.com>
Covid-19 <always.look@message.header>
Corvid <bl@ckbirds.net>
Corvid <bl@ckbirds.org>
Cows Are Nice <cows@nice.moo>
Cows are nice <moo@cows.org>
Cows are Nice <nice@cows.moo>
dogs <dogs@home.com>
Edward H. <dtgamer99@gmail.com>
Edward Hernandez <dtgamer99@gmail.com>
Great Pumpkin <pumpkin@patch.net>
Jose Curvo <jcurvo@mymail.com>
Local Favorite <how2recycle@palomar.info>
Peter Weiner <dtgamer99@gmail.com>
Sea <freshness@coast.org>
Standard Poodle <standard@poodle.com>
triangles <build@home.com>
and others...

-- 
Edward Hernandez <dtgamer99@gmail.com> wrote:

> Path: eternal-september.org!reader02.eternal-september.org!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx13.ams4.POSTED!not-for-mail
> From: Edward Hernandez <dtgamer99@gmail.com>
> Subject: Re: Skybuck's Universal Memory Architecture
> Newsgroups: sci.electronics.design
> References: <66879f56-52f1-4df4-8663-4703fd9c0e3fn@googlegroups.com> <skkufv$fq7$7@dont-email.me>
> Lines: 18
> Message-ID: <XfobJ.738253$r4y9.609590@usenetxs.com>
> X-Complaints-To: https://www.astraweb.com/aup
> NNTP-Posting-Date: Tue, 19 Oct 2021 00:25:27 UTC
> Date: Tue, 19 Oct 2021 00:25:27 GMT
> X-Received-Bytes: 1186
> Xref: reader02.eternal-september.org sci.electronics.design:649665
> 
> The John Doe troll stated the following in message-id 
> <sdhn7c$pkp$4@dont-email.me>:
> 
>> The troll doesn't even know how to format a USENET post...
> 
> And the John Doe troll stated the following in message-id 
> <sg3kr7$qt5$1@dont-email.me>:
> 
>> The reason Bozo cannot figure out how to get Google to keep from 
>> breaking its lines in inappropriate places is because Bozo is 
>> CLUELESS...
> 
> And yet, the clueless John Doe troll has itself posted yet another
> incorrectly formatted USENET posting on Mon, 18 Oct 2021 23:03:27 -0000
> (UTC) in message-id <skkufv$fq7$7@dont-email.me>.
> 
> 7xvG+FXvOfJs
> 
> 
> 

The John Doe troll stated the following in message-id 
<sdhn7c$pkp$4@dont-email.me>:

> The troll doesn't even know how to format a USENET post...

And the John Doe troll stated the following in message-id 
<sg3kr7$qt5$1@dont-email.me>:

> The reason Bozo cannot figure out how to get Google to keep from 
> breaking its lines in inappropriate places is because Bozo is 
> CLUELESS...

And yet, the clueless John Doe troll has itself posted yet another
incorrectly formatted USENET posting on Tue, 19 Oct 2021 00:29:50 -0000
(UTC) in message-id <skl3hu$b5g$3@dont-email.me>.

dXLr2ttmwhGR

skybuck2000 <skybuck2000@hotmail.com> wrote in news:66879f56-52f1-4df4-
8663-4703fd9c0e3fn@googlegroups.com:

> The Problem:
> 

 The problem is you posting off topic stupid shit in our group.

  You were told to leave, so get the fuck out, troll punk motherfucker.

John Doe <always.look@message.header> wrote in news:skl3hu$b5g$3@dont-
email.me:

  You going behind others' posts and then posting a full header quote 
and an inane retarded dumbfuck troll comment has to be the most stupid 
behavior in Usenet followed closey by the idiot you keep stalking the 
posts of.

  The only thing more stupid than Donald John Trump is a Trump 
supporter.  But you...  You, DoeTard are a special case of extreme 
stupidity.

On Tuesday, October 19, 2021 at 6:33:42 AM UTC+2, DecadentLinux...@decadence.org wrote:
> skybuck2000 <skybu...@hotmail.com> wrote in news:66879f56-52f1-4df4- 
> 8663-4703...@googlegroups.com: 
> 
> > The Problem: 
> > 
> 
> The problem is you posting off topic stupid shit in our group. 

How come transistors are off topic in this group ?!  You gonna have to explain that one !

:P

Send me picture of your motherfucking face so I can tell if you get anything going for you.

Bye Bye,
  Skybuck.

Skysuck, listen to your daddy...

-- 
DecadentLinuxUserNumeroUno@decadence.org wrote:

> Path: eternal-september.org!reader02.eternal-september.org!aioe.org!5U2ooNuM5UP0Ynf/GmOnCg.user.46.165.242.91.POSTED!not-for-mail
> From: DecadentLinuxUserNumeroUno@decadence.org
> Newsgroups: sci.electronics.design
> Subject: Re: Skybuck's Universal Memory Architecture
> Date: Tue, 19 Oct 2021 04:33:37 -0000 (UTC)
> Organization: Aioe.org NNTP Server
> Message-ID: <sklhr0$hgp$2@gioia.aioe.org>
> References: <66879f56-52f1-4df4-8663-4703fd9c0e3fn@googlegroups.com>
> Injection-Info: gioia.aioe.org; logging-data="17945"; posting-host="5U2ooNuM5UP0Ynf/GmOnCg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
> User-Agent: Xnews/5.04.25
> X-Notice: Filtered by postfilter v. 0.9.2
> Xref: reader02.eternal-september.org sci.electronics.design:649706
> 
> skybuck2000 <skybuck2000@hotmail.com> wrote in news:66879f56-52f1-4df4-
> 8663-4703fd9c0e3fn@googlegroups.com:
> 
>> The Problem:
>> 
> 
>  The problem is you posting off topic stupid shit in our group.
> 
>   You were told to leave, so get the fuck out, troll punk motherfucker.
> 
> 

Shut up, Skysuck.

-- 
skybuck2000 <skybuck2000@hotmail.com> wrote:

> X-Received: by 2002:a05:6214:20a2:: with SMTP id 2mr341373qvd.13.1634654897174;        Tue, 19 Oct 2021 07:48:17 -0700 (PDT)
> X-Received: by 2002:a25:bcd1:: with SMTP id l17mr10262695ybm.449.1634654896852; Tue, 19 Oct 2021 07:48:16 -0700 (PDT)
> Path: eternal-september.org!reader02.eternal-september.org!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: sci.electronics.design
> Date: Tue, 19 Oct 2021 07:48:16 -0700 (PDT)
> In-Reply-To: <sklhr0$hgp$2@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: <66879f56-52f1-4df4-8663-4703fd9c0e3fn@googlegroups.com> <sklhr0$hgp$2@gioia.aioe.org>
> User-Agent: G2/1.0
> MIME-Version: 1.0
> Message-ID: <fd0bdafb-37d7-4cc2-9e45-7204215b1175n@googlegroups.com>
> Subject: Re: Skybuck's Universal Memory Architecture
> From: skybuck2000 <skybuck2000@hotmail.com>
> Injection-Date: Tue, 19 Oct 2021 14:48:17 +0000
> Content-Type: text/plain; charset="UTF-8"
> Lines: 16
> Xref: reader02.eternal-september.org sci.electronics.design:649726
> 
> On Tuesday, October 19, 2021 at 6:33:42 AM UTC+2, DecadentLinux...@decadence.org wrote:
>> skybuck2000 <skybu...@hotmail.com> wrote in news:66879f56-52f1-4df4- 
>> 8663-4703...@googlegroups.com: 
>> 
>> > The Problem: 
>> > 
>> 
>> The problem is you posting off topic stupid shit in our group. 
> 
> How come transistors are off topic in this group ?!  You gonna have to explain that one !
> 
>:P
> 
> Send me picture of your motherfucking face so I can tell if you get anything going for you.
> 
> Bye Bye,
>   Skybuck.
> 
>