stricmp
in [ASM]
|
From: Frank Kotler on 12 Mar 2005 07:32 Sevag Krikorian wrote: > > Frank Kotler wrote: > > Evenbit wrote: > > > > ... > >>Here is my current code for that procedure: > > > > Well, I can't get HLA to assemble this as-is - wants a > > "DoOneValStmt"... Honestly, the more I try to use HLA, the > > less I like it! > > HLA Linux has more bugs due to a smaller user base reporting > them :) Well, my dislike of HLA centers around syntax - the fact that some of the Linux routines are buggy is merely an "interesting project". My inability to assemble it "as-is" was solved by getting my Pascal in order and putting "begin" and "end" in the right places... (haven't got an actual working file, but I can see what HLA is generating) > >>procedure processFile( filename:string ); > >> > >>var > >>myBuff :dword; > >>fOpen :dword; > >>size :dword; > >>curlocat :dword; > >>prelocat :dword; > >> > >>begin processFile; > >> > >> if( filename = NULL ) then > >> > >> stdout.put( "processFile: NULL" nl ); > >> > >> else > >> > >> stdout.put( "processFile: """, filename, """" nl ); > >> fileio.open( filename, fileio.rw ); > >> mov( eax, fOpen ); > >> fileio.position( fOpen ); > >> mov( eax, prelocat ); > >> mem.alloc((type dword 1024)); > >> mov( eax, myBuff ); > >> while( !fileio.eof( fOpen ) ) do > >> fileio.read( fOpen, myBuff, 1024 ); .... > Humm, I thought I covered that when I mentioned fileio.read > expects a pointer to byte. Sorry if I wasn't clear. Well, yes and no... I wasn't certain whether we were going to end up passing "offset myBuff" or "[myBuff]" (if you know what I mean). Since "myBuff" is a "stack variable", it doesn't really have an "offset", so I figured [contents] was more likely, but nooo... [contents] of fOpen (the "handle" or "file descriptor") get pushed as expected, but HLA generates this code to attempt to "push offset myBuff"... push dword ptr [ebp-16] /* fOpen */ push ebp add dword ptr [esp], -12 pushd 0x400 call STDIO_FREAD /* read */ To me, this seems "unexpected"! Is going through a register the only way to generate the intended code? There must be some way to get "push dword ptr [ebp - 12]" out of it! (besides "#asm"!)... "[myBuff]" doesn't work... Cryptic, this high level assembler! > >>I guess I'll just > >>suffer the consequences when Beth the quantom sourcerous causes that > >>elephant to appear over my head. ;-) > > > > ... "sourceress", you mean :) > > Methinks somebody has been curling up with a Douglas Adams novel. Why are there chunks of whale meat lying all about? Best, Frank
From: Randall Hyde on 12 Mar 2005 11:55 "Frank Kotler" <fbkotler(a)comcast.net> wrote in message news:423289B9.A0D969F2(a)comcast.net... > Evenbit wrote: > > ... > > Here is my current code for that procedure: > > Well, I can't get HLA to assemble this as-is - wants a > "DoOneValStmt"... Honestly, the more I try to use HLA, the > less I like it! The fundamental problem with the sample program at hand is that the "buffer" parameter to fileio.read is passed by "untyped reference". This means that HLA will take the address of *whatever* you pass as a parameter. The following code, therefore, won't work properly because myBuff is itself a pointer, not a buffer. So you're passing the address of a pointer rather than the address of a buffer. Easily fixed by calling fileio.read as follows: fileio.read( fOpen, val myBuff, 1024 ); // Pass value of myBuff rather than its address > > > procedure processFile( filename:string ); > > > > var > > myBuff :dword; > > fOpen :dword; > > size :dword; > > curlocat :dword; > > prelocat :dword; > > > > begin processFile; > > > > if( filename = NULL ) then > > > > stdout.put( "processFile: NULL" nl ); > > > > else > > > > stdout.put( "processFile: """, filename, """" nl ); > > fileio.open( filename, fileio.rw ); > > mov( eax, fOpen ); > > fileio.position( fOpen ); > > mov( eax, prelocat ); > > mem.alloc((type dword 1024)); > > mov( eax, myBuff ); > > while( !fileio.eof( fOpen ) ) do > > fileio.read( fOpen, myBuff, 1024 ); > > mov( eax, size ); > > I think this is your problem. "fileio.read", as I understand > it, is *supposed* to return the number of bytes read, but > look at the code! Yes, it is supposed to. The BytesRead statement is a carry-over from the Windows code that doesn't belong there. It's gone in HLA v1.75. > Yes. The HLA Standard Library should be put on CVS (or > similar) somewhere, so the "million pairs of eyes" can clean > up some of the bugs. Well, a dozen eyes, perhaps :-) Seriously, though, my goal *is* to put the HLA Standard Library on Source Forge (or something similar) when HLA v2.0 rolls around. The only reason for not doing it today is because there will need to be some changes to the code for HLA v2.0 and there is no sense in having people waste a whole lot of time with v1.x of the library. The sources *are* available on Webster, and I *have* been pretty good about fixing problems that are brought to my attention. > > Sevag's suggestion to use the stack, instead of "mem.alloc" > is a good one, but it doesn't solve the problem of what's > wrong with *this* code... No, the problem with the code is the fact that fileio.read uses an untyped VAR parameter. Actually, Sevag's suggestion would probably fix the problem, if you declared the stack-based buffer as var mybuff:byte[1024]; Then HLA would properly take the address of this buffer. But, and this is very important, people who want to use the library functions need to learn the difference between pass by value, pass by reference, and (especially) pass by untyped reference. They all do different things to the parameters you pass to a procedure. In the HLA v2.0 version of the Standard Library, my goal is to make the parameter passing mechanisms a bit more general and all people to pass whatever they want, however they want (largely by providing overloaded functions that recognize the type of parameter you're passing). Until then, it's always a good idea to look carefully at the prototypes for the functions (in the include files, of course, never trust the documentation if you're having problems). Cheers, Randy Hyde
From: Evenbit on 12 Mar 2005 13:38 Frank Kotler wrote: > > Well, my dislike of HLA centers around syntax - the fact > that some of the Linux routines are buggy is merely an > "interesting project". My inability to assemble it "as-is" > was solved by getting my Pascal in order and putting "begin" > and "end" in the right places... (haven't got an actual > working file, but I can see what HLA is generating) I agree that the syntax seems a little over-complicated for an assembler (especially one aimed at beginners). I am constantly jumping back-n-fourth between HLA Ref <=> Stdlib docs <=> AoA trying to keep all the rules straight. > To me, this seems "unexpected"! Is going through a register > the only way to generate the intended code? There must be > some way to get "push dword ptr [ebp - 12]" out of it! > (besides "#asm"!)... "[myBuff]" doesn't work... Cryptic, > this high level assembler! Yeah, it kinda seems counter-intuitive at times. Nathan.
From: Betov on 12 Mar 2005 16:43 "Evenbit" <nbaker2328(a)charter.net> ýcrivait news:1110652731.785942.275750 @o13g2000cwo.googlegroups.com: > it kinda seems counter-intuitive at times. Quite normal for an HLL-Pre-Parser. Of course, that one is one of the most stupid we ever saw, but all HLL-Pre-Parsers tend to behave like this. Why don't you try Assembly, instead. Assembly is a very simple and easy language, where each component of a Source is clearly identified and immidiately understandable. That's one of the great advantages of Assembly on HLLs. Betov. < http://rosasm.org/ >
From: Randall Hyde on 12 Mar 2005 17:45
"Frank Kotler" <fbkotler(a)comcast.net> wrote in message news:4232E151.64C11C07(a)comcast.net... > ... > > Humm, I thought I covered that when I mentioned fileio.read > > expects a pointer to byte. Sorry if I wasn't clear. Actually, it takes the address of whatever variable you supply. Including the address of a *pointer* variable, if you supply a pointer variable. > > Well, yes and no... I wasn't certain whether we were going > to end up passing "offset myBuff" or "[myBuff]" (if you know > what I mean). Since "myBuff" is a "stack variable", it > doesn't really have an "offset", so I figured [contents] was > more likely, but nooo... [contents] of fOpen (the "handle" > or "file descriptor") get pushed as expected, but HLA > generates this code to attempt to "push offset myBuff"... "[" and "]" in HLA are used strictly for indexes. Strike all thought of memory from your mind when you use them :-). > > push dword ptr [ebp-16] /* fOpen */ > push ebp > add dword ptr [esp], -12 > pushd 0x400 > call STDIO_FREAD /* read */ Not unexpected at all. Again, an "untyped pass by reference" parameter always computes the address of the operand you provide. The operand, in this case, is myBuff which just happens to be sitting at EBP-12 on the stack. I believe you'll agree that push ebp add dword ptr [esp], -12 pushes the address of this object onto the stack. > > To me, this seems "unexpected"! Is going through a register > the only way to generate the intended code? There must be > some way to get "push dword ptr [ebp - 12]" out of it! > (besides "#asm"!)... "[myBuff]" doesn't work... Cryptic, > this high level assembler! There are several ways to achieve what you want: 1. Don't use the HLL-like calling sequence. That is, you can always write code like the following: push( fOpen ); push( myBuff ); push( 1024 ); call stdin.fread; 2. You can use a hybrid calling sequence: stdin.read( fOpen, #{ push( myBuff); }#, 1024 ); 3. Or you could simply tell HLA to use the value of myBuff rather than its address: stdin.read( fOpen, val myBuff, 1024 ); Cheers, Randy Hyde |