flat assembler
Message board for the users of flat assembler.

Index > Heap > Future of computers and CPU's


How long will the existing XXX86/XXX64 architecture remain acceptable ???
1. It's excellent, including all 16-bit and 32-bit legacy support, uber-alles, state-of-the-art, ..., for all times
25%
 25%  [ 3 ]
2. Legacy crap sucks, drop all 16-bit and 32-bit legacy support, pure XXX64 is the best, uber-alles, state-of-the-art, ..., for all times
8%
 8%  [ 1 ]
3. Something new will be needed one day ... but not soon please ;-)
41%
 41%  [ 5 ]
4. XXX86/XXX64 heavily sucks, too old and too bloated, throw it away and brew something new and better, much better, much simpler, NO legacy crap compatibility, better today than tomorrow
16%
 16%  [ 2 ]
5. Back to stone age, please, I don't need any CPU architecture
8%
 8%  [ 1 ]
Total Votes : 12

Author
Thread Post new topic Reply to topic
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
See also:

http://board.flatassembler.net/topic.php?t=14893 "Golden era of home computers"

http://board.flatassembler.net/topic.php?t=12900 "Intel manuals"

The existing (FASM supported) CPU architecture dates from 1978 (8086 introduced back then, XXX64 still can execute 8086 code, and recycles many 8086 ideas) or even 1974 (8080 introduced back then, 8086 broke compatibility with 8080, but still recycles many 8080 ideas, some of them persist until now in XXX64). Intel documentation is absurdly bloated (5000 pages now ???).

THE QUESTION: will this architecture persist for all times, or will it or should it get replaced ? If you know by what, please post your ideas. What are the worst design faults of the existing architecture ?

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 25 Dec 2012, 13:47
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17467
Location: In your JS exploiting you and your system
revolution
ARM is going to 64-bit soon, and supposedly it is a new reworked ISA (although as yet no manuals are public to confirm this claim). However it will still support the current 32-bit "legacy" modes so as not to make all existing code obsolete.

I think that x86 may lose 16-bit support soon, but 32-bit is still very useful and more efficient than 64-bit so 32-bit won't be disappearing for a very long time.

We will always be stuck with legacy support for ever and ever. It is just part of the cost of keeping the newest CPUs relevant and sellable.
Post 25 Dec 2012, 14:38
View user's profile Send private message Visit poster's website Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1413
Location: Toronto, Canada
AsmGuru62
The big issue as I see it -- if chip architecture changed completely - such a chip will not
be able to run a lot of software (I mean a LOT!).
For new architecture -- new compilers are needed. All code needs to be
rebuild. Who is gonna pay for this? Software manufacturers? ....hmmm... not likely.

The move to a completely new architecture supposed to be gradual, like move from DOS to Windows.
New chips should implement TWO instruction sets, so if anyone wants they can take advantage on new instructions (I hope new arc. is better. If not -- all that just BS talk).
Post 25 Dec 2012, 16:55
View user's profile Send private message Send e-mail Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 22:08; edited 1 time in total
Post 25 Dec 2012, 20:01
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> The big issue as I see it -- if chip architecture changed completely -
> such a chip will not be able to run a lot of software (I mean a LOT!).

LOT ... it will run no existing software Sad

> Who is gonna pay for this?

Bill could ... theoretically Very Happy

> The move to a completely new architecture supposed to be
> gradual, like move from DOS to Windows.

That's why Windows is that bloated. buggy, and inefficient (and only the OS got "switched", not the CPU, and not other hardware ...)

> New chips should implement TWO instruction sets, so if anyone
> wants they can take advantage on new instructions

XXX64 can execute 64-bit and 32-bit and 16-bit code ... even real mode ... and to make obsolete stuff even more happy, it provides excessive "virtualization technology" ...
Post 26 Dec 2012, 08:06
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1413
Location: Toronto, Canada
AsmGuru62
I code for Windows since 1992 and it is a fine OS.
I do not see any bloat or inefficiency. We have tera-byte drives today, so
no issue with bloat.

Also, can you demo for me any bugs in Windows?
And I do not mean security vulnerabilities or GUI choice
("I wanna see this icon here and not there..." type of thing).

Show me something, where I call API and it does not do what it is supposed to do.
I know just a couple of those -- with thousands of API functions. It is not
that bad and there is always workaround.
Post 26 Dec 2012, 11:40
View user's profile Send private message Send e-mail Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4240
Location: 2018
edfed
brand new architecture needed, with only the more used instructions, native 64 bits adressing and datas, with 32 , 16 and 8 bits subadressing and subdatas to optimise a little when needed.

no more crap please, but for that, should before kill many people cause they will always add useless or crappy features, it is stronger than them.
Post 26 Dec 2012, 14:31
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> I do not see any bloat

over 10 GiB for XXX64, and several 10K files ...

> or inefficiency

OK:

0. how to peek keyboard (AKA kbhit) easily
1. how to put a char on console screen easily
2. how to do graphics (port DOS 320x200 apps) easily ...
3. how to read filesystem directories easily
4. how to play sound easily and reliably (even VLC can't ...)
5. how to brew a process without file? NO WAY Sad
6. consider all the duplicate and >2-plicate API's: DoBlah, DoBlahEx, DoBiggerBlah, DoBiggerBlahEx, ...
7. consider all the filename/path issues (peek some "mainstream" projects, not my evil ideas)
8. all the ".NET" stuff (Win32 API is obsolete ???)
9. memory protection is too complicated and still not reliable
10. "EXPLORER": what is it? an app? part of the kernel? can Windows live without it? why many people do launch it again and again, despite it is already running?
11. can't exist without the GUI
12. IE, WMP, ..., other things not properly separated from the kernel
13. drivers must (?) have GUI and installer ... why???
14. all the WDM/VXD mess in ME/98 (OK, no VXD's anymore, now XXX86/XXX64 issues instead)
15. drivers need extra support for Win16 and extra support for NTVDM
16. PE is full of obscure/obsolete stuff

do you need more???

> We have tera-byte drives today, so no issue with bloat

I've seen this argument already 1'000'000'000'000 (billion AKA 10^12 AKA Tera) times, but not convinced yet ...

> Also, can you demo for me any bugs in Windows?

See above

> And I do not mean security vulnerabilities

As there are 1'000'000's of them ...

> or GUI choice ("I wanna see this icon here and
> not there..." type of thing).

Some more BUG's:

0. frequent BS's (in ME, less bad in XP)
1. file I/O issues: attribute issues (DIR with "R" attribute ???), spaces in filenames, path length limit not reliable, faulty char's in names, random behavior with faulty pathes, RECYCLE BIN LADEN should be a feature of the filesystem and not of the OS, OS should be properly separated from the filesystem, ...

> Show me something, where I call API and it
> does not do what it is supposed to do.

See above ... for example

0. send a faulty path to the OS ... result is B***-S*** ... and on every version different
1. send garbage to MessageBox ... OS may TripleFault Very Happy
2. try some "advanced" stuff ... result is unpredictable due to "DirectX" bad version or even missing, ...
3. try to do something ... it may fail due to "security" restrictions

> I know just a couple of those -- with thousands of API functions

This is exactly the inefficiency I'm referring to Smile

> It is not that bad and there is always workaround

Right ... this is another part of the problem.

> brand new architecture needed, with only the more used
> instructions, native 64 bits adressing and datas, with 32 ,
> 16 and 8 bits subadressing and subdatas to optimise a
> little when needed.

That's one of the things what I am thinking of. 64-bit maximum, 32-bit and 16-bit supported and included in a simple, smooth and efficient way.
Post 26 Dec 2012, 16:09
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1413
Location: Toronto, Canada
AsmGuru62
Sorry, not convincing enough.
I still see no real bugs.
10Gb is 1% of a drive. No big deal - let it be twice that.
Post 26 Dec 2012, 21:24
View user's profile Send private message Send e-mail Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
AsmGuru62, it is not a space problem. It is true, the hard disks are big these days, but the information on the 1TB hard disk is dead and useless information. In order to be useful it need to be loaded in the RAM, you know. Here becomes the big problem - all these GBs of information bouncing from the disk to the ram back and forth. That is why the big size means low speed and small size almost always means high speed.
Post 26 Dec 2012, 21:54
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2913
Location: 0x77760000
typedef
DOS386 wrote:
> I do not see any bloat

over 10 GiB for XXX64, and several 10K files ...

> or inefficiency

OK:

0. how to peek keyboard (AKA kbhit) easily
1. how to put a char on console screen easily
2. how to do graphics (port DOS 320x200 apps) easily ...
3. how to read filesystem directories easily
4. how to play sound easily and reliably (even VLC can't ...)
5. how to brew a process without file? NO WAY Sad
6. consider all the duplicate and >2-plicate API's: DoBlah, DoBlahEx, DoBiggerBlah, DoBiggerBlahEx, ...
7. consider all the filename/path issues (peek some "mainstream" projects, not my evil ideas)
8. all the ".NET" stuff (Win32 API is obsolete ???)
9. memory protection is too complicated and still not reliable
10. "EXPLORER": what is it? an app? part of the kernel? can Windows live without it? why many people do launch it again and again, despite it is already running?
11. can't exist without the GUI
12. IE, WMP, ..., other things not properly separated from the kernel
13. drivers must (?) have GUI and installer ... why???
14. all the WDM/VXD mess in ME/98 (OK, no VXD's anymore, now XXX86/XXX64 issues instead)
15. drivers need extra support for Win16 and extra support for NTVDM
16. PE is full of obscure/obsolete stuff

do you need more???

> We have tera-byte drives today, so no issue with bloat

I've seen this argument already 1'000'000'000'000 (billion AKA 10^12 AKA Tera) times, but not convinced yet ...

> Also, can you demo for me any bugs in Windows?

See above

> And I do not mean security vulnerabilities

As there are 1'000'000's of them ...

> or GUI choice ("I wanna see this icon here and
> not there..." type of thing).

Some more BUG's:

0. frequent BS's (in ME, less bad in XP)
1. file I/O issues: attribute issues (DIR with "R" attribute ???), spaces in filenames, path length limit not reliable, faulty char's in names, random behavior with faulty pathes, RECYCLE BIN LADEN should be a feature of the filesystem and not of the OS, OS should be properly separated from the filesystem, ...

> Show me something, where I call API and it
> does not do what it is supposed to do.

See above ... for example

0. send a faulty path to the OS ... result is B***-S*** ... and on every version different
1. send garbage to MessageBox ... OS may TripleFault Very Happy
2. try some "advanced" stuff ... result is unpredictable due to "DirectX" bad version or even missing, ...
3. try to do something ... it may fail due to "security" restrictions

> I know just a couple of those -- with thousands of API functions

This is exactly the inefficiency I'm referring to Smile

> It is not that bad and there is always workaround

Right ... this is another part of the problem.

> brand new architecture needed, with only the more used
> instructions, native 64 bits adressing and datas, with 32 ,
> 16 and 8 bits subadressing and subdatas to optimise a
> little when needed.

That's one of the things what I am thinking of. 64-bit maximum, 32-bit and 16-bit supported and included in a simple, smooth and efficient way.


*sigh*

You mad bro. Shocked

Btw, .NET is ok too. It's for rapid development and I as a freelancer do enjoy it.

Go back to your "terminal cave" if you don't like Explorer, otherwise adjust your attitude or code your own OS. Hell, even your screen name says DOS ! Hypocrite Twisted Evil
Post 27 Dec 2012, 05:51
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
typedef wrote:
Go back to your "terminal cave"


I will Smile (even more considering you quoted my complete post for no reason)

typedef wrote:
DOS386 wrote:
typedef wrote:
DOS386 wrote:
typedef wrote:
DOS386 wrote:
typedef wrote:
DOS386 wrote:
typedef wrote:
DOS386 wrote:
YES
NO
YES
NO
YES
NO
YES
NO
YES
NO


http://www.extremetech.com/computing/127791-china-plans-national-unified-cpu-architecture

Interesting link ^^^ from other thread ... answered the question from above "Who is gonna pay for this?" From technical point of view this is highly interesting news, but I don't like China's politics at all, so this could be dangerous news at the end Sad

> I still see no real bugs

1. BUG #1
2. BUG #2
3. BUG #3
Post 27 Dec 2012, 07:27
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1413
Location: Toronto, Canada
AsmGuru62
Again, not convincing.

#1 is a compatibility issue (not an API)
#2 is not an API call
#3 is improper usage (only service can call that message box)

Here is what a bug is (from a coder POV):

1. Call an API with PROPER parameters (MSDN).
2. A crash must happen or API is not working as specified.
Post 27 Dec 2012, 11:30
View user's profile Send private message Send e-mail Reply with quote
typedef



Joined: 25 Jul 2010
Posts: 2913
Location: 0x77760000
typedef
1 is not a bug rather a requirement.
2. Is not a bug. That's why the executable flag exists to mark a memory region executable.
3. Maybe... Laughing
Post 27 Dec 2012, 11:34
View user's profile Send private message Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 22:08; edited 1 time in total
Post 27 Dec 2012, 13:30
View user's profile Send private message Reply with quote
Spool



Joined: 08 Jan 2013
Posts: 154
Spool
[ Post removed by author. ]


Last edited by Spool on 17 Mar 2013, 04:30; edited 1 time in total
Post 22 Jan 2013, 18:46
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17467
Location: In your JS exploiting you and your system
revolution
Spool wrote:
So when ARM is going to 64-bit the opcode length will also be 64-bit?
No. Still 32-bit opcode length.
Post 22 Jan 2013, 18:51
View user's profile Send private message Visit poster's website Reply with quote
matefkr



Joined: 02 Sep 2007
Posts: 1291
Location: Ukraine, Beregovo
matefkr
well, with the technology i discovered, we can launch communication satellites everywhere and have them geostationary on each point on earth, and almost all the pople who can afford computers can afford a satellite to be launched every second month or such.. so everony have highslpeed point to point connection to whatever things fairly fast. no need for stupid rooters and shit. all built into the large machines, the end devices of stupid humans are just simple console communicator whatever. the radio to the satellite is directed as the satellite can be geostationary everywhere.. (well you need a power relay thingy because it needs some power wich is received from the sun.. so when its shadowy.. mabe the accumulator cannot be large enough to hold the sattellite on spot, so the energy is beemed from other sunny satellites.. but anyway.
so the architecture.. is something simple for terminal and large machines here and there.. with general processing and flexible computational capabilities for number of transistors.
Post 23 Jan 2013, 12:12
View user's profile Send private message Reply with quote
matefkr



Joined: 02 Sep 2007
Posts: 1291
Location: Ukraine, Beregovo
matefkr
although i dont have to mention.. people would use it for several sort of bullshit. now with even more speed. thats why good centralized machine structure with the interfaces in peoples hands. the bullshit is easier to sort. i dont think most people need consumer equipment of machines and such. i think replacing their timewasting activity with the computer entirely with simple sports games and sexual activities work easily. mabe they need some communicator device or tracker to look up where eachothers are to organize shit but thats it. there would be a need for a lot of scientists who would recquire blahblah and blahblahblah still it would not cost so much traffic. rather the ai would have eyes placed somewhere else and could use it for looking. not needed so much for humans.
Post 23 Jan 2013, 12:25
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.