flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Non-x86 architectures > Mill CPU architecture

Author
Thread Post new topic Reply to topic
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14469
Location: ?                               Posts: 6699
Mill CPU architecture
http://ootbcomp.com/docs/

No GP registers. Single address space but still using page tables. They claim up to 33 operations per cycle. Each CPU version needs different binary code so assembly might not be supported, instead using loader code to generate the bits at runtime.

But it is also vapourware so maybe nothing will come of it.
Post 19 Apr 2014, 10:40
View user's profile Send private message Visit poster's website Reply with quote
alexfru



Joined: 23 Mar 2014
Posts: 29
There are some clever ideas. But you never know. They might deliver. Or they might get bought without delivering the Mill to the market. They can be seen as a threat to the existing products or as a useful resource. There might be some value in their patents (I don't know how many they've applied for and how many they've got or what's in them besides the content of the publicly available videos and slides). I don't think they'll just disappear as if never existed.
Post 19 Apr 2014, 12:06
View user's profile Send private message Reply with quote
sid123



Joined: 30 Jul 2013
Posts: 340
Location: Asia, Singapore
There is a looooooooooooooooooooooooooooooooong discussion here: http://forum.osdev.org/viewtopic.php?f=15&t=27743
Post 19 Apr 2014, 12:36
View user's profile Send private message Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 670
Location: Adelaide
Lost me at "terrorism".
Post 19 Apr 2014, 12:37
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14469
Location: ?                               Posts: 6699
The fact that that binary encodings change depending upon the specific CPU configuration means that if an assembler was to be used then it would have to generate different code for each target CPU that it will be run on.

Also the source code might need changing for each CPU model because basic things like belt length are different and thus needs different handling within the expression of the algorithms.

It is not clear to me whether each implementation of the same specced CPU will use the same encodings. There appears to be an automatic generator used to define the encodings and no human is involved the the bit allocation. So if there is some new method used or an algorithmic improvement in the bit encoding it could be that a newer version of the same specced chip would have a different binary instruction encoding. And this is the point (if correct) that would kill assembly code on a practical level and force the use of the "specialiser" to convert intermediate code into hardware opcodes.
Post 20 Apr 2014, 04:02
View user's profile Send private message Visit poster's website 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 cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.