Quote:
Originally Posted by britelite
At least the sources for the 32bit version are available for download. Not that it will convince you anyway...
|
Available for download, huh ? And... where ?
Quote:
Originally Posted by Thorham
The challenge? For fun? Academic practice?
|
That's nothing worth so much touble...
Quote:
Originally Posted by Thorham
If that game is commercial than the reason for lying is obvious, but this OS isn't commercial, so they have no reason to, apart from people saying how crazy they must be for writing an OS in asm.
|
There are so many fakes for so many things in the internet, so why not that ?
Quote:
Originally Posted by Thorham
It's not all that incredible. It's perhaps more work than writing a similar OS in 68k, but if people can manage to get to the moon in 1969, then writing an OS in x86 asm seems like easy cakes  |
Yes but it depends how far you push the concept of "OS". If it's just some odd kernel running on a very limited set of machines, with very few APIs and next to zero apps, then yes it's possible.
Quote:
Originally Posted by Thorham
Could be interesting to hear!
|
You *do* want the list, hmm ?
A few have been mentioned here already if you paid attention to them, but here are a few annoyances (nothing close to the horror it is on other cpu families, obviously) :
. no eor from mem
. no exg in mem
. two carries (as i said, minor, but nevertheless valid, shortcoming)
. code density could have been better, especially with immediates
. 020+ strange modes (more problematic for the implementation though)
. addressing modes missing from movem
. lack of flexibility for address registers
. a7 shouldn't have been sp
. duplicate encodings for same operation (add #i vs addi)
. pc-relative modes not writeable (even though i know the design reason for this)
. lack of flexibility for shift operations
. ipl=0 is exact same as ipl=1 (not an annoyance but an oddity)
. vector table not exactly clean and compact
. stack frame incompatibility over members of the family
. no byte index, but nothing to ease extending values either
. strange compatibility tricks : move ccr, byte push/pop doing a7 +2/-2
. dbf limited to 0..n and word size
. many instructions needlessly touch the ccr (or some bits of it)
And of course it's not difficult to "invent" extra instructions that would be quite practical to have.
@Megol: seems you were wrong when you wrote i just can't say anything remotely bad about 68k.