Holiday Game
in [ASM]
|
Prev: Win32 non blocking console input?
Next: hugi compo #29
From: Chuck Crayne on 3 Dec 2008 00:14 On Tue, 2 Dec 2008 02:00:35 -0800 "Rod Pemberton" <do_not_have(a)nohavenot.cmm> wrote: > I'll just assume > it's some twisted variation of NASM syntax. I like to think that I am tolerant of other folks assembly language syntax, as long as I don't have to use it myself, but what condemns HLA to the scrap heap of history is that Randy has created a "standard" library so complete that he is unlikely to live long enough to port it to 64 bit mode. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Chuck Crayne on 3 Dec 2008 00:15 On Sun, 30 Nov 2008 12:57:02 -0800 (PST) NathanCBaker(a)gmail.com wrote: > This is crude (un-polished) mock-up of a Fifteen (Sliding) Puzzle > game. Good work! Now, how about a gui version? -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: NathanCBaker on 3 Dec 2008 18:29 On Dec 2, 5:41 am, Herbert Kleebauer <k...(a)unibwm.de> wrote: > NathanCBa...(a)gmail.com wrote: > > On Dec 1, 7:33 am, Herbert Kleebauer <k...(a)unibwm.de> wrote: > > > Does HLA now support optimization or do you really use the div instruction to > > > dived by 4? > > > Optimization!?!? You want to optimize a simple console game?? I > > think an explicit division instruction enhances the readability -- > > If you want readability, use a HLL (and then you also get speed > because the compiler doesn't use the div instruction when you > write /4 in your source). > In psuedo: func y ( a, b, c ) { return a + ( b / c ) } Will the HLL compiler generate code such that in the event that c = 4, the code will not execute the div instruction?? > > which is probably more important than execution speed these days. > > Heck, even 'xor eax, eax' is a bit steep for today's readers. Take a > > Then better don't do any assembly programming than this way. > So, you agree with me that 'mov( 0, eax )' is better readable? > > You'll need the Randy Hyde x86 processor manual which describes these > > fancy new machine instructions ( e.g. rand.randomize, mem.alloc, > > etc. ): > > HLA is maybe the most important contribution in killing assembly > programming (if it really is use for teaching assembly programming > as Randy claims). > I think the biggest obstacle is lack of interest in detail among the younger generation... and maybe also a bit of laziness. > Now compare your source code with this C program, which is better > readable? > > #include <stdio.h> > #define n (('|'<<24)+(' '<<16)+('0'<<8)) > unsigned int feld[4][4]; > > int main() > {int i,j,k,x=0,y=0; > > for (i=0; i<4; i++) for (j=0; j<4; j++) > feld[i][j]= n + (((k='0'+i*4+j)<='9')?k:k-'0'-10+'a'); > > print(); > > while ((i=getchar())!='q') > {switch(i) > {case 'a': if (x==0) putchar(0x07); > else {feld[x][y]=feld[x-1][y]; x--;} break; > case 'd': if (x==3) putchar(0x07); > else {feld[x][y]=feld[x+1][y]; x++;} break; > case 'w': if (y==0) putchar(0x07); > else {feld[x][y]=feld[x][y-1]; y--;} break; > case 's': if (y==3) putchar(0x07); > else {feld[x][y]=feld[x][y+1]; y++;} break; > case '\n': continue; > default: putchar(0x07); > } > feld[x][y]= n + '0'; > print(); > } > > } > > int print() > {int i,j,k; > for (i=0; i<4; i++) > {for (j=0; j<4; j++) for (k=24; k>=0; k=k-8) putchar(feld[j][i]>>k); > putchar('\n');} > > } Are you trying to say that a C compiler makes a good assembler? Would you teach people assembly language by simply teaching them to write C code? Nathan.
From: NathanCBaker on 3 Dec 2008 18:42 On Dec 2, 12:42 pm, "Jim Carlock" <jcarl...(a)127.0.0.1> wrote: > <NathanCBa...(a)gmail.com> wrote... > > <snip>...</snip> > > The message to Nathan appears after the message to Randall. > > This message goes to Randall... I tried to get hla.exe to output > the parameters to a file as follows: > > Z:\source\hla\nathan>hla.exe -? >> hla.txt > > (1) I ended up with the same > > "Press the enter key to continue:" > > messages. It would be nice to get all those parameters into a text > file in a normal convenient way. :-) I'll leave them posted here > to help others out. > That's my fault! I asked him to add that because the terminal window for Win98 doesn't have a scrollbar and I didn't know (at the time) about the ">>" trick for redirecting of stderr. > (2) I ended up with ALOT of whitespace as well. It would be nice > to NOT have ALL that WHITESPACE. I removed it from what follows > in order to make it NICE for everyone here that wants to copy it. > > (3) I counted over 100 lines of whitespace between block of 12 or > 13 lines. > The entire dang thing is horribly long. I started to convert it into a man file until I realized the amount of time I'd have to put into the task. > And one last question... which version of HLA are you compiling > with? > version 1.103 > I believe I have the same problem Frank has, as I installed the latest > version of HLA (HLA Update) on top of what was previously there and I > end up with the following messages (errors?): > > Z:\source\hla\nathan>hla.exe -v sliders.hla > HLA (High Level Assembler) > Use '-license' to see licensing information. > Version Version 1.103 build 20419 (prototype) > Win32 COFF output > OBJ output using internal FASM back-end > -test active > > HLA Lib Path: Z:\hla\hlalib > HLA include path: Z:\hla\include > HLA temp path: > Linker Lib Path: Z:\PSDK\20010627\Lib\.;Z:\hla > > Files: > 1: sliders.hla > > Compiling 'sliders.hla' to 'sliders.obj' > using command line: > [hlaparse -WIN32 -level=high -v -sf -ccoff -test "sliders.hla"] > > ---------------------- > HLA (High Level Assembler) Parser > use '-license' to view license information > Version Version 1.103 build 20418 (prototype) > -t active > File: sliders.hla > Output Path: "" > hlainc Path: "Z:\hla\include" > Compiler running under Windows OS > Back-end assembler: FASM > Language Level: high > > Compiling "sliders.hla" to "sliders.obj" > Error in file "os.hhf" at line 5 > syntax error, unexpected namespaceTkn, expecting DoOneValStmt. > Near: << namespace >> > This hints at a copy-N-paste error. { looking back at my original post, yep, I goofed! } Add a "program fifteen;" line at the beginning just above the "#include" directive. Nathan.
From: NathanCBaker on 3 Dec 2008 18:53
On Dec 3, 12:14 am, Chuck Crayne <ccra...(a)crayne.org> wrote: > On Tue, 2 Dec 2008 02:00:35 -0800 > > "Rod Pemberton" <do_not_h...(a)nohavenot.cmm> wrote: > > I'll just assume > > it's some twisted variation of NASM syntax. > > I like to think that I am tolerant of other folks assembly language > syntax, as long as I don't have to use it myself, but what condemns HLA > to the scrap heap of history is that Randy has created a "standard" > library so complete that he is unlikely to live long enough to port it > to 64 bit mode. > Correct. His best path of action should be to abandon the lib in favor of a 64-bit C library. Nathan. |