Significant Pure Assembler Application In MASM ?
in [ASM]
|
Prev: aeBIOS Test Request
Next: CMOVcc vs. Jcc
From: Herbert Kleebauer on 8 Oct 2007 04:28 santosh wrote: > Herbert Kleebauer wrote: > >> It more than a "beginning." Tell me one reasonable thing that you can > >> do with your Windows that I cannot do with my Ubuntu here. > > > > Try to execute a binary you generated with Linux ten years ago. > > Yes compile your kernel with a.out support added in. The file format isn't the problem (I don't think they will change it every year). The problem seems to be the libraries and the kernel API. And I don't care about the past, but there must be some day where they declare a final version 1.0 of the API to which all later versions will be backward compatible. It doesn't make any sense to develop software for a continuously changing system. > > In Windows I can execute DOS programs written twenty years ago > > (and I hope MS will be forced by the user base to also include > > 16 bit support in 64 bit Windows). > > Whatever. Why not also force them to support binaries written for the > PDP, OS/360 and MULTICS? ??? All I expect is, that when I write software for a system, this software will also run on a new version of the same system. Just imagine, every new version of Acrobat reader couldn't display pdf files generated for a previous version. > > For me Linux becomes an > > alternative to Windows (as a desktop system) only if: > > > > 1. There is a version where they can guarantee that any BINARY > > written for this version can be executed on any newer release > > (for at least ten years). > > I think this guarantee is already there in practise. ??? Wasn't easy to find a binary of Midnight Commander which was happy with my Linux version. Don't know if there is a NASM binary which can be executed on all Linux versions not older than two years. > > 2. This also must be true for the graphics (multimedia) system. > > This means, the OS and THE (we don't need more than one) graphics > > system has to be unified like in Windows. > > Now you're talking like Betov. X Windows is universal under Linux and > UNIXes. Integrating it into the kernel has not been done for obvious > reasons. UNIXes run on a far wider variety of hardware than Windows and > in situations where a GUI is not needed. But if Linux want to be a replacement for a mainstream OS like Windows, there has to be a version with a bundled graphics interface (by the OS and not by the distribution).
From: Betov on 8 Oct 2007 04:40 santosh <santosh.k83(a)gmail.com> �crivait news:feclhk$elk$1(a)aioe.org: > How exactly? Something like GTK is available wherever X is available. I > think this fear of getting "locked in" is just paranoia. As you seem to be aware... does there exist something like the Windows Debug APIs under Linux? >> I'm not ready to count ReactOS out. > > It's not ever going to become a serious replacement for Windows unless > Microsoft themselves start sponsoring it, and then it'll be a "poor > man's" Windows, much like the "Windows Starter Edition" available > today. You might be right on the point. May be this is the real plan of the criminals having actually control on ReactOS and deliberately committing piracies to the trunck. This would perfectly match with my expectations, about having them taking the very same path as Lindows. Betov. < http://rosasm.org >
From: Betov on 8 Oct 2007 04:57 Herbert Kleebauer <klee(a)unibwm.de> �crivait news:4709EA39.F33F47CC(a)unibwm.de: > if Linux want to be a replacement for a mainstream OS like > Windows, there has to be a version with a bundled graphics interface > (by the OS and not by the distribution). Yes. Do you think a GTK bet could be wise? Betov. < http://rosasm.org >
From: Herbert Kleebauer on 8 Oct 2007 05:22 Betov wrote: > Herbert Kleebauer <klee(a)unibwm.de> �crivait > > if Linux want to be a replacement for a mainstream OS like > > Windows, there has to be a version with a bundled graphics interface > > (by the OS and not by the distribution). > > Yes. Do you think a GTK bet could be wise? I don't know anything, but I think Linus refuses to add the graphical subsystem to the core OS and X is much to slow for graphic games. I don't know whether GTK works with OpenGL.
From: Wolfgang Kern on 8 Oct 2007 05:28
"Betov" replied: >> I just finished a rewrite of my formatted numeric I/O routines and >> gained more than 20% speed and saved about 15% space while adding >> more features :) >> Many parts could be improved by only reorder structs and reuse >> already existing code parts > Sure. It is often times very difficult to understand where time > can be saved. I would now choose something like the CheckSum64 > stuff of RosAsm for the Symbols Table. When i applied this, i > was rather surprised of the improvement. From what i have seen, > i suppose that the encoder could be twice faster (at least), by > applying the same method to Mnemonics. Maybe to the Registers > also. What is sure, is that, in matter of speed, it is better > to waste a bit of memory, with big tables, than to think about > directly improving the speed of the code in a parser. This > seems to be always worthy the wasted time at creating the > CheckSum. Right, my disass.bin use tables for everything, including text for register-names and mnemonics. And a few wasted bytes in this tables make all items equal sized (usually 2^n zero/space padded), so they can be accessed easy and fast, ie: D$RegNames+rm*4 ;"eax ,ecx ,... D$Grp0mnem+ttt*4 ;"ADD ,OR ,... and also for the [literally:]literally longer instructions, I use either 8-byte or (rare) 16-byte elements in the tables. Your assembler may need to use such tables in the opposite direction and I'd try if sorted index trees aren't much faster than hash algos. __ wolfgang tables |