Skybuck's Universal Code 5 (The Native Version)

[Skybuck Flying]

Hello,

I just had an idea for another universal code version 5.

The idea is as follows:

32 bit integer, 32 bit pointer, 32 bit integer, 32 bit pointer, 32 bit
integer, 32 bit pointer.

The 32 bit pointer is nil, if no more integers follow.

The 32 bit pointer points to the next integer in memory if there does follow
another integer.

This idea will execute very fast on cpu's I am sure.

Another benefit is the integers can grow very easily, because the next
integer can be anywhere in memory.

Finally when the data structure needs to be stored on disk or any other
storage medium it would be wise to store it sequentially.

This can be done by simply replacing the pointers with a special value to
indicate more integers follow, finally the nil pointer will follow
to indicate it was the last integer.

Well I have my doors open, and the car/busses stink, busy day today. So I am
gonna sign off for now.

But definetly interesting idea to speed stuff up and still allow flexibility


Bye,
Skybuck.

 

[[email protected]]

Hello,

I just had an idea for another universal code version 5.

The idea is as follows:

32 bit integer, 32 bit pointer, 32 bit integer, 32 bit pointer, 32 bit
integer, 32 bit pointer.

The 32 bit pointer is nil, if no more integers follow.

The 32 bit pointer points to the next integer in memory if there does follow
another integer.

This idea will execute very fast on cpu's I am sure.

Another benefit is the integers can grow very easily, because the next
integer can be anywhere in memory.

Finally when the data structure needs to be stored on disk or any other
storage medium it would be wise to store it sequentially.

This can be done by simply replacing the pointers with a special value to
indicate more integers follow, finally the nil pointer will follow
to indicate it was the last integer.

Well I have my doors open, and the car/busses stink, busy day today. So I am
gonna sign off for now.

But definetly interesting idea to speed stuff up and still allow flexibility


Bye,
  Skybuck.

As usual, I have no idea what you're talking about. However, it
1) Looks like pure software, what is this doing here?
2) Sounds like a linked list, pretty much one of the most basic things
in comp sci.

 

[Alex Colvin]

32 bit integer, 32 bit pointer, 32 bit integer, 32 bit pointer, 32 bit

integer, 32 bit pointer.

This idea will execute very fast on cpu's I am sure.

not on 36-bit CPUs.

 

[Danny Strümpel]

As usual, I have no idea what you're talking about. However, it
1) Looks like pure software, what is this doing here?
2) Sounds like a linked list, pretty much one of the most basic things
in comp sci.

Yes, a very much easier implementation would just be

type
TSomething = array of Integer;

or in form of a linked list

type
PInt = ^TInt;
TInt = record
Value: Integer;
Next: PInt;
end;

Don't have a clue what he recently "invented" with his pageful of
description.

 

[Anthony Fremont]

not on 36-bit CPUs.

I've only worked with one of those, but it was for about 20 years. Octal
rocks.

 

[ChairmanOfTheBored]

I just had an idea for another universal code version 5.

You just had another epiphany of stupidity.

 

[MooseFET]

Hello,

I just had an idea for another universal code version 5.

The idea is as follows:

32 bit integer, 32 bit pointer, 32 bit integer, 32 bit pointer, 32 bit
integer, 32 bit pointer.

The 32 bit pointer is nil, if no more integers follow.

The 32 bit pointer points to the next integer in memory if there does follow
another integer.

You have just reinvented the "linked list". If you want to do this
right, you should move the "Next" pointer to before the contents.
After the "Next" pointer, put the VMT[1] and after that the text of
the value.

[1] VMT = Virtual Method Table. Normally it contains the routines for
processing the value that follows, for speed, in your case it should
contain the microcode address table for the CPU.

This idea will execute very fast on cpu's I am sure.

Actually it will be much slower than a simple array. A well designed
CPU can process its way down an array much faster than down a linked
list. This is because the new address can be prepared while the
contents for the old one are being processed. The CPU saves a read
time for getting the address and the internal bus transfer time for
moving it from the data bus to the address bus.

Another benefit is the integers can grow very easily, because the next
integer can be anywhere in memory.

Not if you limit the addresses to 32Bits. There is a computer out
there somewhere that has over 1T of RAM and runs Linux.

Finally when the data structure needs to be stored on disk or any other
storage medium it would be wise to store it sequentially.

Actually this may not be the case. You are assuming that the data is
best stored sequentially when storing it as groups may work better.

 

[MooseFET]

As usual, I have no idea what you're talking about. However, it
1) Looks like pure software, what is this doing here?
2) Sounds like a linked list, pretty much one of the most basic things
in comp sci.

Dec used to make a machine called the "link". It had a purely
hardware indirect reference action. If the MSB of a pointer was set,
it was used as a pointer to a pointer. There was no limit to how many
deep you could chain pointers. It was a very odd machine.

 

[Clifford Heath]

Dec used to make a machine called the "link". It had a purely
hardware indirect reference action. If the MSB of a pointer was set,
it was used as a pointer to a pointer. There was no limit to how many
deep you could chain pointers. It was a very odd machine.

You're thinking of the DG Nova

 

[Skybuck Flying]

Now that a new day has broken it's time to clearify some things about my
recent invention hahahahaha =D

1. It does look like a linked list. However linked lists are usually used to
store individual elements.

In this case the entire linked list is a single element or integer. It's one
big integer.

A scalable integer for that matter.

2. I believe the linked list is a better structure than an array.

An array has troubles growing. The array will collide with other structure
in memory.

When that happens the array needs to be moved, which means an expensive
copy.

A linked list does not have this drawback.

Thus I believe the linked list could prove to be a faster data structure on
the long run.

What is true and what is not true remains to be seen and might be different
per usage case.

However the linked list has pretty much consistent performance. It will
functions longer in fragmented memory than a huge array.

Huge arrays will start to fail in fragmented memory. And defragmentation
will need to occur for array's. Not so for linked lists.

This linked list can function very long before it becomes a problem.

Finally there is a performance penalty for linked list where
arbitrary/random memory positions are used.

This is not free. Even RAM has I/O limitation. Each access for RAM requires
time. However sequantially accessed data is much faster than randomly
accessed data.

This speaks in favor for the array. However I have also mentioned drawbacks
for arrays.

It's hard to say if the adventage of the array outperforms the drawback of
the array.

Finally a linked list can perform rougly the same as the array if the memory
positions are chosen to be near each other.

Thus the linked list is a more flexible structure and can adept more
flexibly to different operating conditions.

Now some other operating requirements.

For large integers it's necessary to be able to move back forth through the
integer list.

For example multiplication and division probably require to be able to go up
and down the list.

Or maybe multiplication and division require only to be able to re-iterate
the list.

Hmm let's see, multiplication might be done via re-iterate.

However division works from the opposite site and starts at the largest
integers.

This might create a little problem.

The division algorithm must iterate to the top. But then it has no way to
return to the bottom.

Unless it keeps track of all the integer it encountered.

This is a clear drawback.

However different solutions come to mind:

Solution 1:

1. Alter the universal code, by making it a doubly linked list. This would
tripple memory requirements. Which is undesirable.

2. Keep track of pointers/elements during algorithms. Provide a recycle list
of elements/integer/pointers for fast list building.

This makes algorithms must more complex which is also kinda unreliable.

Which solution is chosen is up to the implementor.

Remember, this is just an idea, I do not recommend you follow any ideas of
mine. If you do follow any ideas of mine, it's your own risk

Bye,
Skybuck.

 

[Chris Thomasson]

Now that a new day has broken it's time to clearify some things about my
recent invention hahahahaha =D

1. It does look like a linked list. However linked lists are usually used
to store individual elements.

In this case the entire linked list is a single element or integer. It's
one big integer.

A scalable integer for that matter.

2. I believe the linked list is a better structure than an array.

[...]

Do you know about pointer chasing?

 

[Skybuck Flying]

One last note:

To truely make it a universal code the pointers could be relative to itself.

So the location of the pointer itself functions as base zero.

This way the maximum gap between elements is 2^32 bytes or something like
that.

Which means unlimited ammounts of memory can be used as long as the gaps
between the sub integers is never exceeded.

This ideas requires extra processing though:

Take the address of the pointer and add the contents of the pointer to the
address to get the final address of the next element.

Not to bad... just a few instructions extra.

Bye,
Skybuck.

 

[Skybuck Flying]

Linked lists can be used for many things.

Has it been used before, for infinite integer arithmetic ?

Can you give examples ?

Bye,
Skybuck.

 

[sycochkn]

Hello,

I just had an idea for another universal code version 5.

The idea is as follows:

32 bit integer, 32 bit pointer, 32 bit integer, 32 bit pointer, 32 bit
integer, 32 bit pointer.

The 32 bit pointer is nil, if no more integers follow.

The 32 bit pointer points to the next integer in memory if there does
follow
another integer.

You have just reinvented the "linked list". If you want to do this
right, you should move the "Next" pointer to before the contents.
After the "Next" pointer, put the VMT[1] and after that the text of
the value.

[1] VMT = Virtual Method Table. Normally it contains the routines for
processing the value that follows, for speed, in your case it should
contain the microcode address table for the CPU.

This idea will execute very fast on cpu's I am sure.

Actually it will be much slower than a simple array. A well designed
CPU can process its way down an array much faster than down a linked
list. This is because the new address can be prepared while the
contents for the old one are being processed. The CPU saves a read
time for getting the address and the internal bus transfer time for
moving it from the data bus to the address bus.

Another benefit is the integers can grow very easily, because the next
integer can be anywhere in memory.

Not if you limit the addresses to 32Bits. There is a computer out
there somewhere that has over 1T of RAM and runs Linux.

Finally when the data structure needs to be stored on disk or any other
storage medium it would be wise to store it sequentially.

Actually this may not be the case. You are assuming that the data is
best stored sequentially when storing it as groups may work better.

you store the data with the links If you want to sort you make a new list of
links using recursion.
a single pass sort.

bob

 

[Skybuck Flying]

Yes, a very much easier implementation would just be

type
TSomething = array of Integer;

Limited to 2 GigaByte.

or in form of a linked list

type
PInt = ^TInt;
TInt = record
Value: Integer;
Next: PInt;
end;

Unlimited in case next pointer uses it's own address as base zero.

Bye,
Skybuck.

 

[Skybuck Flying]

What you mean storing it as a group ?

Storing it sequentially or storing it as a group is the same thing to me at
least.

So explain yourself if you believe you were not mistaken.

Bye,
Skybuck.

 

[Robert Baer]

Hello,

I just had an idea for another universal code version 5.

The idea is as follows:

32 bit integer, 32 bit pointer, 32 bit integer, 32 bit pointer, 32 bit
integer, 32 bit pointer.

The 32 bit pointer is nil, if no more integers follow.

The 32 bit pointer points to the next integer in memory if there does follow
another integer.

This idea will execute very fast on cpu's I am sure.

Another benefit is the integers can grow very easily, because the next
integer can be anywhere in memory.

Finally when the data structure needs to be stored on disk or any other
storage medium it would be wise to store it sequentially.

This can be done by simply replacing the pointers with a special value to
indicate more integers follow, finally the nil pointer will follow
to indicate it was the last integer.

Well I have my doors open, and the car/busses stink, busy day today. So I am
gonna sign off for now.

But definetly interesting idea to speed stuff up and still allow flexibility


Bye,
Skybuck.

(yawn) LISP

 

[ChairmanOfTheBored]

Now that a new day has broken it's time to

**** off, this is a hardware group.

 

[Skybuck Flying]

This is serious first get a new nickname.

Bye,
Skybuck.

 

[Skybuck Flying]

No wait, disregard that advice.

Dumbass like you need to blocked by me.

Welcome to my ban list.

Bye,
Skybuck.