Linux X demo
in [ASM]
|
Prev: masm linking from console
Next: NASM HelloWorld - DOS
From: Betov on 24 Jul 2007 02:07 "Rod Pemberton" <do_not_have(a)nowhere.cmm> �crivait news:f83k1c$9mf$1 @aioe.org: > Good luck, you'll need it... :)) With a write-only Language, i am afraid everybody will. :)) Betov. < http://rosasm.org >
From: Rod Pemberton on 24 Jul 2007 02:44 "Rod Pemberton" <do_not_have(a)nowhere.cmm> wrote in message news:f83ic5$5hp$1(a)aioe.org... > > "Wolfgang Kern" <nowhere(a)never.at> wrote in message > news:f80d7e$kn5$1(a)newsreader2.utanet.at... > > > > Rod Pemberton asked: > > > > >> A hung ? > > >> the ESC-key terminates this (former) unmoveable, frontmost box. > > >> Latest upload is moveable and can be minimised (even only by taskbar). > > >> > > > > > Damn... you want me to dl it again and tell you if it's fixed, > > > don't you? > > > > :) TIA, <sub> yes please </sub> :) > > > > Okay, the splash screen comes up with a bunch of check boxes and then > invalid instruction error: > > HEXTUTOR executed an invalid instruction in > module HEXTUTOR.EXE at 0167:0041aaf2. > Registers: > EAX=00000001 CS=0167 EIP=0041aaf2 EFLGS=00010246 > EBX=00000000 SS=016f ESP=0054fca0 EBP=0054fce8 > ECX=00000000 DS=016f ESI=00008d40 FS=1097 > EDX=80005170 ES=016f EDI=0054fcd0 GS=0000 > Bytes at CS:EIP: > 0f 45 15 40 30 40 00 0f 44 15 3c 30 40 00 51 0f > Stack dump: > 0041aaa8 0041a3f3 0041a291 0054fcd0 00008d40 0054fce8 > 0054fccc 0054fd1c 00008d5c 00000000 00000000 bff7363b > 00000b2c 0000000f 00000000 00000000 > > 32-bit PM? cmovnz and/or cmovz ? They're unsupported by my CPU... Do you detect CPU via CPUID? Rod Pemberton
From: Phil Carmody on 24 Jul 2007 04:51 "Rod Pemberton" <do_not_have(a)nowhere.cmm> writes: > "Phil Carmody" <thefatphil_demunged(a)yahoo.co.uk> wrote in message > news:87sl7gbnbu.fsf(a)nonospaz.fatphil.org... > > Do you believe that the order of evaluation of a[--i]=i follows > > from precedence? > > > > I just told you it does for pre-ANSI C. > > I quoted the exact phrase by Dennis Ritchie of one the six "C gods" > (Ritchie, Kernighan, Plauger, Gwyn, Harbison, Steele) stating that it does. You quoted: <<< "7. Expressions The precedence of expression operators is the same as the order of the major subsections of this section (highest precedence first). ... Within each subsection, the operators have the same precedence. Left or right associativity is specified in each subsection for the operators discussed therein. The precedence and associativity of all the expression operators is summarized in an appendix. Otherwise the order of evaluation of expressions is undefined. In particular the compiler considers itself free to compute subexpressions in the order it believes most efficient, even if the subexpressions involve side effects." >>> > Unfortunately, you didn't seem to comprehend what he stated and just > reiterated your prior beliefs. > > Read the all of the many precedences in Section 7. Unlike ISO C, everything > in the la[--j]= statement is defined by precedence and therefore order of > evaluation. Well, it does say that ``la[--i]'' is to be evaluated before ``la[--i]=i''. It also says that ``--i'' is to be evalutate before ``la[--i]''. That much I evidently have no issue with. It does *not* say that ``la[--i]'' is to be evaluated before ``i''. As an aside, by considering more complicated expressions, if anything there's a weak implication that ``i'' should be evaluated before ``la[--i]''. I'll leave that little conundrum as a teaser for you to work out, as it's not entirely obvious. So, the compiler may do this, and conform to the above paragraph: The value of ``i'' is that of i The value of ``--i'' is that of i-1, I'll worry about side effects later. The value of ``la[--i]'' is that of la[i-1] The value of ``la[--i]=i'' is that of i, and I'll put i in la[i-1]. Now I'll tidy up my side effects and set i to i-1. That's exactly in line with precedence. Maybe your source from 1974, which almost certainly isn't the version of the language under question, elsewhere states that side effects must be enacted at the time of the evaluation of the sub-expression they are a side effect of. It would also have to justify the evaluation of ``la[--i]'' before ``i''. However, that's *not* in what you've quoted. I'm also absolutely sure that the 1978 K&R that I used to have made no such mention of when the side effects were comitted. > The concept of sequence points where the statement is dissolved > into separate evaluatable pieces, partially to deal with volatile, doesn't > apply. > > Good luck, you'll need it... Many thanks; you too. Phil -- "Home taping is killing big business profits. We left this side blank so you can help." -- Dead Kennedys, written upon the B-side of tapes of /In God We Trust, Inc./.
From: Frank Kotler on 24 Jul 2007 05:51 Herbert Kleebauer wrote: > Frank Kotler wrote: > >>I took the "regular linker" version out of retirement, updated it to > > More than 4 times the size compared to the directly generated binary! True. I guess I forgot to mention "strip -R.comment myprog" - three times the size, but still... I haven't figured out why the "direct to binary" version isn't working. Some mis-match between the header and where I've actually told Nasm to put the data, I think. The only way Nasm can switch from "bits" to "nobits" (uninitialized data) is by starting a new "section", and then it won't subtract labels in different sections. Rather than employ "Brian Raiter's method", which would be the "usual Nasm way", I've tried to get clever... and it isn't working. I'll keep picking at that - I haven't really spent much time on it. I'd like to get "that way" working. The "asmutils" elf.inc macros do something even simpler than "your way". Everything goes in one section, and if there's any writeable data, the whole thing is made writeable. We may be able to get it even smaller that way... if that's the "goal"... >>Herbert's latest version (mostly), and got *that* running, finally. > > But with awful colors (did you really convert it by hand?). I haven't got my autoconverter done yet. :) It might be more accurate to say "attempted to ...". >> test eax, eax ; ERROR >> js err >> >> ; my apologies for propagating this sloppiness. >> ; really should be "cmp eax, -4096" (or -4095?) >> ; won't happen here, but we *could* get a >> ; valid return over 2G! - fbk > > > If there are bugs, you should correct them instead of propagating > them! It isn't much of a "bug". Just "sloppiness". My "latest and greatest" code *does* attempt to do this right, but cut-and-paste, y'know - there's a lot of the old stuff floating around. > I just looked at the man pages in UBUNTU Linux and it says: > -1 is returned for an error. Can't at moment check the man pages > in Linspire Linux but somewhere I must have got the information > that a negative return value is an error (where did you get the > information about -4096). I don't know.(!) The man pages will tell you that the calls return -1 on error, and the error number's in "errno". With the int 80h interface, there's no "errno" - the error number (*minus* error number - they're defined positive) is in eax. Randy had some instances where he checked for -1, specifically, in old hlalib code, and I pointed out to him that he wouldn't be seeing that, except for -EPERM, and that he should just check for negative. He immediately questioned me on that, pointing out that we couldn't manage memory over 2G if that were so. I didn't know the correct answer at the time, but it's "-4096" (since we're managing memory in pages, we won't get a valid return above this). Vid confirmed this recently in some of his complaints about hlalib, too. I'm sure it's "in the book" somewhere, but I don't know where. > Even the include paths are different > between the two Linux versions. And yet, "make install" generally works. .... >> shr eax, 2 > > should be a "shr al,2", the color table has only 64 entries. Oops! That's the problem with putting the size in the instruction... where it can so easily be deleted. :) All those "r0"s look the same to me. I've cleaned up quite a few of those "translation errors", but there are probably more I've missed. Sorry, Annie - didn't mean to give ya a broken heart! :) .... >> popa >> ; nop ??? > > There was a popad bug in the 386, so my assembler always generates a > nop after a popad. Then it isn't an assembler, is it? Okay, reintroduced. Any 386s running X have got enough problems without triggering their bugs. .... >> mov eax, 0 ; sic > > I know, a compiler never would do this, but we are only human > assembly programmers. Horrible bloat, Herbert! I'm obsessive enough that I changed it, though. :) > Did you find more bugs? Well, I haven't got the "direct to binary" version working. I didn't find anything I'd call a "bug" in your code. I'll keep lookin'! :) Best, Frank
From: Herbert Kleebauer on 24 Jul 2007 16:25
Frank Kotler wrote: > Herbert Kleebauer wrote: > True. I guess I forgot to mention "strip -R.comment myprog" - three > times the size, but still... > > I haven't figured out why the "direct to binary" version isn't working. I also tried it but failed because I couldn't convince NASM to modify the current location counter $ without outputting data. It didn't accept a second org statement nor a resb statement (warning: uninitialized space declared in .text section: zeroing). But this is necessary to combine text and data in one page (the same page is loaded twice in memory, once for text and once for data section). > The "asmutils" elf.inc macros do something even simpler than "your way". > Everything goes in one section, and if there's any writeable data, the > whole thing is made writeable. We may be able to get it even smaller > that way... if that's the "goal"... I don't think it will be smaller (in my version there also is no gap in the file between text and data). But it's the only way to do it with NASM if it is impossible to modify $ in the text section without outputting code. > ... > >> popa > >> ; nop ??? > > > > There was a popad bug in the 386, so my assembler always generates a > > nop after a popad. > > Then it isn't an assembler, is it? Sure it is. It just uses the opcode "61 90" for the popad instruction which, in opposite to the opcode "61", also works on a 386 without any problem. > ... > >> mov eax, 0 ; sic > > > > I know, a compiler never would do this, but we are only human > > assembly programmers. > > Horrible bloat, Herbert! This mostly happens when I initialize a register with a value <>0 and then later change it to 0. |