From magli143 at gmail.com Sun Jul 2 16:11:31 2006 From: magli143 at gmail.com (Magnus Lind) Date: Sun, 02 Jul 2006 23:11:31 +0200 Subject: [Slackers] Slang v1.4 released In-Reply-To: References: Message-ID: <44A83683.7020200@gmail.com> Steve Judd wrote: > Just a short note that slangv1.4 (which is b1.22) is available on the web Great release, I've been trying it out for a few hours today and all array pointer stuff I need/want to do work as expected :). A question: The following code generates some warnings about "Fewer dims than expected". Are all instances of this warning correct? I seem to be unable to avoid it whenever I try to assign the location of an array to an array pointer. --------------------------------------- ubyte str(10) ubyte ^strp(10) strp = #"test1" strp = #str strp = str test(#"test2") test(str) test(#str) test(strp) sub test(ubyte ^outdata(0)) endsub --------------------------------------- Also, I seem to have found a bug. However its no big deal since its easy to work around. Here's a short example that provokes a "hey cool, a phase error" message from the compiler: --------------------------------------- ubyte i, j ubyte str(10) if 0<1 str(i) = str(j) endif --------------------------------------- while this example doesn't: --------------------------------------- ubyte i, j ubyte str(10) if 0<1 j = str(j) str(i) = j endif --------------------------------------- Finally, how about that big endian stored int type (16 bit signed, for BASIC interoperability)? Would it be much work? Is it something that I can do myself by modifying slangdef/userdef or is the type stuff embedded deeper in the language core? /Regards Magnus Lind From sjudd at ffd2.com Mon Jul 3 10:21:34 2006 From: sjudd at ffd2.com (Steve Judd) Date: Mon, 3 Jul 2006 09:21:34 -0600 (MDT) Subject: [Slackers] Slang v1.4 released In-Reply-To: <44A83683.7020200@gmail.com> References: <44A83683.7020200@gmail.com> Message-ID: Hey Magnus, > A question: The following code generates some warnings about "Fewer dims > than expected". Are all instances of this warning correct? I seem to be Looks like I forgot to put a pointer exception in there. In general, arrays don't require you to specify all dimensions. The reason is for things like ubyte screen(25,40)@$0400 screen(17) = 0 as well as strings and such. (Code like screen(17,0) will generate code to add zero to the pointer -- which is really something to fix, I suppose...) > Also, I seem to have found a bug. However its no big deal since its easy > to work around. Here's a short example that provokes a "hey cool, a > phase error" message from the compiler: > --------------------------------------- > ubyte i, j > ubyte str(10) > str(i) = str(j) This is a bad bug. Very foolish of me. My guess is that it's a byproduct of the recent optimization that does "ldx i lda str,x". So, I blame Jaymz. But I'll try to get a fix done sooner rather than later, since this is a very fundamental thing. > Finally, how about that big endian stored int type (16 bit signed, for > BASIC interoperability)? Would it be much work? Is it something that I > can do myself by modifying slangdef/userdef or is the type stuff > embedded deeper in the language core? To do this, you'd need to modify slangdef. First, a new type would need to be added, e.g. "basint". That's easy. The hard part is that you'd need to rewrite all of the operators, if you were going to use these in an expression. Remember that any expression has ARGL, ARGR, and DEST: "ARGL + ARGR -> DEST". So you'd have to be able to handle all combinations (e.g. int + basint -> basint). Probably the easiest way would be to first convert this basint type to a regular int, then operate, then convert to the dest type. But at that point I'd ask myself, why not just perform conversion at the point of calling basic functions? So yup, big-endian ints could be added, but it would be quite a lot of work, and I believe it would be far simpler (and generate better code) to simply add type conversion to the call to the basic routine (before or after the call, as needed). The 6502 really likes little-endian; the big-endian basic int is just a byproduct of the floating-point storage format. After all, BASIC itself doesn't even operate on those ints -- it either convers them to floats (for arithmetic) or converts them to little-endian (for pointers). Did you have a specific application in mind, btw? cu, -Steve From magli143 at gmail.com Mon Jul 3 12:38:33 2006 From: magli143 at gmail.com (Magnus Lind) Date: Mon, 03 Jul 2006 19:38:33 +0200 Subject: [Slackers] Slang v1.4 released In-Reply-To: References: <44A83683.7020200@gmail.com> Message-ID: <44A95619.3030506@gmail.com> Steve Judd wrote: >> Finally, how about that big endian stored int type (16 bit signed, for >> BASIC interoperability)? Would it be much work? Is it something that I >> can do myself by modifying slangdef/userdef or is the type stuff >> embedded deeper in the language core? > > To do this, you'd need to modify slangdef. First, a new type would need > to be added, e.g. "basint". That's easy. like this? ---------------- type basint len 2 fixed signed ---------------- This means that the slang core would see this type exactly like an int, right? > > The hard part is that you'd need to rewrite all of the operators, if you > were going to use these in an expression. Remember that any expression > has ARGL, ARGR, and DEST: "ARGL + ARGR -> DEST". So you'd have to be able > to handle all combinations (e.g. int + basint -> basint). > Probably the easiest way would be to first convert this basint type to a > regular int, then operate, then convert to the dest type. But at that > point I'd ask myself, why not just perform conversion at the point of > calling basic functions? Ah, you mean that I could extend the operators to take basints into consideration by transforming them into normal ints, then operate and then transform back. > > So yup, big-endian ints could be added, but it would be quite a lot of > work, and I believe it would be far simpler (and generate better code) to > simply add type conversion to the call to the basic routine (before or > after the call, as needed). I agree, doing the conversion deeper in the code generator will be more complex and obscure. However, equal code generation quality compared to ints is possible. But then big endian ints would have to be supported by the internal type system of the slang core. Possibly by a type declaration endian modifier like 'fixedbig' or something similar. And this seems to be a far from trivial task :) > > The 6502 really likes little-endian; the big-endian basic int is just a > byproduct of the floating-point storage format. After all, BASIC itself > doesn't even operate on those ints -- it either convers them to floats > (for arithmetic) or converts them to little-endian (for pointers). Yes, I know, the only time when integers are preferable to floats are when using arrays since they take less space. > Did you have a specific application in mind, btw? Well, not really, I did imagine some basic extension that modifies integer arrays. It would have been a little quicker than manual endian conversion since I thought that using a basint type wouldn't need ANY conversion at all. Now I know better :) Ok, just one for the road.. I seem to have found another bug. The following code will loop forever. ------------------------------------ ubyte i for i=0:255 endfor ------------------------------------ However, its very easy to work around by using another flow control construct. /Regards Magnus Lind From sjudd at ffd2.com Mon Jul 3 13:43:18 2006 From: sjudd at ffd2.com (Steve Judd) Date: Mon, 3 Jul 2006 12:43:18 -0600 (MDT) Subject: [Slackers] Slang v1.4 released In-Reply-To: <44A95619.3030506@gmail.com> References: <44A83683.7020200@gmail.com> <44A95619.3030506@gmail.com> Message-ID: Hey Magnus, > like this? > ---------------- > type basint > len 2 > fixed > signed > ---------------- > This means that the slang core would see this type exactly like an int, > right? Yup. > Well, not really, I did imagine some basic extension that modifies > integer arrays. It would have been a little quicker than manual endian > conversion since I thought that using a basint type wouldn't need ANY > conversion at all. Now I know better :) Yeah, I didn't worry about endian conversion. It could probably be made to work, but... > Ok, just one for the road.. > I seem to have found another bug. The following code will loop forever. > ------------------------------------ > ubyte i > for i=0:255 > endfor > ------------------------------------ The most irritating thing about this is that I've fixed this bug like five times already. The recent rewrite of for-next obviously brought it back. I blame Jaymz. cu, -S From bryan.pope at comcast.net Mon Jul 3 13:54:46 2006 From: bryan.pope at comcast.net (Bryan Pope) Date: Mon, 03 Jul 2006 14:54:46 -0400 Subject: [Slackers] Slang v1.4 released In-Reply-To: References: <44A83683.7020200@gmail.com> <44A95619.3030506@gmail.com> Message-ID: <44A967F6.1090303@comcast.net> Steve Judd wrote: > The most irritating thing about this is that I've fixed this bug like five > times already. The recent rewrite of for-next obviously brought it back. > I blame Jaymz. > > Who or what is "Jaymz"?! Cheers, Bryan From jaymz at artificial-stupidity.net Mon Jul 3 19:11:41 2006 From: jaymz at artificial-stupidity.net (Jaymz Julian) Date: Tue, 4 Jul 2006 10:11:41 +1000 Subject: [Slackers] Slang v1.4 released In-Reply-To: <44A967F6.1090303@comcast.net>; from bryan.pope@comcast.net on Mon, Jul 03, 2006 at 02:54:46PM -0400 References: <44A83683.7020200@gmail.com> <44A95619.3030506@gmail.com> <44A967F6.1090303@comcast.net> Message-ID: <20060704101140.A41880@artificial-stupidity.net> On Mon, Jul 03, 2006 at 02:54:46PM -0400, Bryan Pope wrote: > Steve Judd wrote: > > The most irritating thing about this is that I've fixed this bug like five > > times already. The recent rewrite of for-next obviously brought it back. > > I blame Jaymz. > > > > > Who or what is "Jaymz"?! I'm jaymz :). -- -- Jaymz Julian - Coder, Visionary, Fat Ass. "Hannibal is a serial killer. He only likes to kill and eat people. Very few people have `I want to be killed and eaten' on their cards, so Hannibal is out of a job." - http://cards.sf.net From bryan.pope at comcast.net Mon Jul 3 21:17:05 2006 From: bryan.pope at comcast.net (Bryan Pope) Date: Mon, 03 Jul 2006 22:17:05 -0400 Subject: [Slackers] Slang v1.4 released In-Reply-To: <20060704101140.A41880@artificial-stupidity.net> References: <44A83683.7020200@gmail.com> <44A95619.3030506@gmail.com> <44A967F6.1090303@comcast.net> <20060704101140.A41880@artificial-stupidity.net> Message-ID: <44A9CFA1.1000308@comcast.net> Jaymz Julian wrote: > On Mon, Jul 03, 2006 at 02:54:46PM -0400, Bryan Pope wrote: > >> Steve Judd wrote: >> >>> The most irritating thing about this is that I've fixed this bug like five >>> times already. The recent rewrite of for-next obviously brought it back. >>> I blame Jaymz. >>> >>> >>> >> Who or what is "Jaymz"?! >> > > I'm jaymz :). > > The coder behind the scenes?? :) Cheers, Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://starbase.globalpc.net/pipermail/slackers/attachments/20060703/7257ce18/attachment.html From jaymz at artificial-stupidity.net Mon Jul 3 22:00:05 2006 From: jaymz at artificial-stupidity.net (Jaymz Julian) Date: Tue, 4 Jul 2006 13:00:05 +1000 Subject: [Slackers] Slang v1.4 released In-Reply-To: <44A9CFA1.1000308@comcast.net>; from bryan.pope@comcast.net on Mon, Jul 03, 2006 at 10:17:05PM -0400 References: <44A83683.7020200@gmail.com> <44A95619.3030506@gmail.com> <44A967F6.1090303@comcast.net> <20060704101140.A41880@artificial-stupidity.net> <44A9CFA1.1000308@comcast.net> Message-ID: <20060704130005.C41880@artificial-stupidity.net> On Mon, Jul 03, 2006 at 10:17:05PM -0400, Bryan Pope wrote: > > Who or what is "Jaymz"?! > > I'm jaymz :). > The coder behind the scenes?? :) No, the complainer behind the scenes :) --j -- -- Jaymz Julian - Coder, Visionary, Fat Ass. "Hannibal is a serial killer. He only likes to kill and eat people. Very few people have `I want to be killed and eaten' on their cards, so Hannibal is out of a job." - http://cards.sf.net From magli143 at gmail.com Wed Jul 12 11:41:16 2006 From: magli143 at gmail.com (Magnus Lind) Date: Wed, 12 Jul 2006 18:41:16 +0200 Subject: [Slackers] Slang v1.4 released In-Reply-To: References: Message-ID: <44B5262C.3090803@gmail.com> Steve Judd wrote: > Just a short note that slangv1.4 (which is b1.22) is available on the web > page. Found another bug: This test program test some combinations of assigning float constants to different kinds of variables. for some of the cases that dereferences and assigns to out pointer variables cases the compiler to generate bad code. It gets the size of the float type wrong and copies 256 bytes instead of five. The strange thing is that it gets exactly the same scenario right when the variables are 'normal' pointer variables and not out parameters. The example uses 'sub asm' subroutines but the problem exists for 'normal' subroutines too. ----------------------------------------------------------------- sub asm test@$aaaa()_byte ba@$aaaa, int ia@$aaaa, float fa@$aaaa sub asm testp@$aaaa()_byte ^ba@$aaaa, int ^ia@$aaaa, float ^fa@$aaaa sub asm testzp@$aaaa()_byte ^ba@$aa, int ^ia@$aa, float ^fa@$aa byte ba byte ^bap@$aaaa byte ^bazp@$aa int ia int ^iap@$aaaa int ^iazp@$aa float fa float ^fap@$aaaa float ^fazp@$aa ba = 3.14 test_ba = 3.14 ^bap = 3.14 ^bazp = 3.14 ^testp_ba = 3.14 ^testzp_ba = 3.14 ia = 3.14 test_ia = 3.14 ^iap = 3.14 ^iazp = 3.14 ^testp_ia = 3.14 ^testzp_ia = 3.14 fa = 3.14 test_fa = 3.14 ^fap = 3.14 ^fazp = 3.14 ^testp_fa = 3.14 ^testzp_fa = 3.14 --------------------------------------------------------------------- /Regards Magnus Lind From magli143 at gmail.com Wed Jul 12 14:06:21 2006 From: magli143 at gmail.com (Magnus Lind) Date: Wed, 12 Jul 2006 21:06:21 +0200 Subject: [Slackers] Slang v1.4 released In-Reply-To: References: Message-ID: <44B5482D.9080908@gmail.com> Steve Judd wrote: > Just a short note that slangv1.4 (which is b1.22) is available on the web > page. I think I found another bug. This test program fails compilation with a "SetMarker error; yikes!" message. ----------------------------------------------------- ubyte ^buf($100) buf = test2()_buf sub test2()_ubyte ^buf($100)@$62 endsub ----------------------------------------------------- /Regards Magnus Lind From sjudd at ffd2.com Wed Jul 12 19:42:03 2006 From: sjudd at ffd2.com (Steve Judd) Date: Wed, 12 Jul 2006 18:42:03 -0600 (MDT) Subject: [Slackers] Slang v1.4 released In-Reply-To: <44B5482D.9080908@gmail.com> References: <44B5482D.9080908@gmail.com> Message-ID: Hey Magnus, The problem is that in order to work correctly, you have to _believe_ it will work. Once you start to doubt, it will fail in exactly the way you describe. On the other hand... thanks for finding these, and I'll get to work on it soon (hopefully this weekend.) cu, -Steve From magli143 at gmail.com Thu Jul 13 03:55:36 2006 From: magli143 at gmail.com (Magnus Lind) Date: Thu, 13 Jul 2006 10:55:36 +0200 Subject: [Slackers] Slang v1.4 released In-Reply-To: References: <44B5482D.9080908@gmail.com> Message-ID: <44B60A88.6060609@gmail.com> Steve Judd wrote: > The problem is that in order to work correctly, you have to _believe_ it > will work. Once you start to doubt, it will fail in exactly the way you > describe. Well, I do believe features will work when I try to use them. And it got me very far in what I set out to do. Very much of slang obviously works very well :) I'm trying to do a library of helper routines that bridges the gap between basic and slang in slang/assembler. The goal is to make it trivial to write (possibly generate) slang wrapper code in order to make basic commands of slang subroutines. This involves many opportunities to test 'sub asm' constructs that calls into the basic ROM and returns pointers in zero page. > On the other hand... thanks for finding these, and I'll get to work on it > soon (hopefully this weekend.) Thats great. As before, since it is possible to in-line assembly code, almost all bugs can be worked around, so theres no genuine hurry. /Regards Magnus Lind From jaymz at artificial-stupidity.net Wed Jul 19 00:09:20 2006 From: jaymz at artificial-stupidity.net (Jaymz Julian) Date: Wed, 19 Jul 2006 15:09:20 +1000 Subject: [Slackers] Slang v1.4 released In-Reply-To: ; from sjudd@ffd2.com on Sat, Jun 24, 2006 at 10:18:45AM -0600 References: Message-ID: <20060719150920.B15121@artificial-stupidity.net> On Sat, Jun 24, 2006 at 10:18:45AM -0600, Steve Judd wrote: > Just a short note that slangv1.4 (which is b1.22) is available on the web > page. Hey, I finally found some time for coding again :). Just a note, though - the xlang zip file contains a binary called 'xlang', which is the old version, and 'a.out' which is the new version - oops :) --jj -- -- Jaymz Julian - Coder, Visionary, Fat Ass. "Hannibal is a serial killer. He only likes to kill and eat people. Very few people have `I want to be killed and eaten' on their cards, so Hannibal is out of a job." - http://cards.sf.net From jaymz at artificial-stupidity.net Wed Jul 19 00:24:33 2006 From: jaymz at artificial-stupidity.net (Jaymz Julian) Date: Wed, 19 Jul 2006 15:24:33 +1000 Subject: [Slackers] Slang v1.4 released In-Reply-To: <20060719150920.B15121@artificial-stupidity.net>; from jaymz@artificial-stupidity.net on Wed, Jul 19, 2006 at 03:09:20PM +1000 References: <20060719150920.B15121@artificial-stupidity.net> Message-ID: <20060719152433.C15121@artificial-stupidity.net> On Wed, Jul 19, 2006 at 03:09:20PM +1000, Jaymz Julian wrote: > On Sat, Jun 24, 2006 at 10:18:45AM -0600, Steve Judd wrote: > > Just a short note that slangv1.4 (which is b1.22) is available on the web > > page. > > Hey, I finally found some time for coding again :). Just a note, though - > the xlang zip file contains a binary called 'xlang', which is the old version, > and 'a.out' which is the new version - oops :) Also, there seems to be a new bug in the parser, possibly relating to external definitions - or at least, my use of them. I have a sprite.inc that looks like: ----------------------------------------------------------------------------- numSprites equ 16 ; external plexor defines uint ext spriteX(numSprites) ubyte ext spriteY(numSprites) ubyte ext spritePtr(numSprites) ubyte ext spriteColour(numSprites) ubyte ext spriteOrder(numSprites) ; plexor functions sub ext setMainIrq(int i) sub ext initSpriteSystem() sub ext placeEightSprites() sub ext spriteSort() ----------------------------------------------------------------------------- Any attempt to use these variables results in some kind of odd parse error - depending on what mood the compiler is in, it varies from a "Parenthethis mithmatch" to a "Hey, cool, a phase error" message. This is on code that compiled acceptably on the previous release :). Now, it might be that the ext stuff is a red herring, since I just found that the phase error is actually just near a use of bitTable, which is defined such: ----------------------------------------------------------------------------- ubyte bitTable(16)=[ 1 1 2 2 4 4 8 8 16 16 32 32 64 64 128 128 ] ubyte ibitTable(16)=[ 254 254 253 253 251 251 247 247 239 239 223 223 191 191 127 127 ] ----------------------------------------------------------------------------- So I suppose it is quite possible that it is in fact related to small arrays some how... I'm clueless on this one :( --jj -- -- Jaymz Julian - Coder, Visionary, Fat Ass. "Hannibal is a serial killer. He only likes to kill and eat people. Very few people have `I want to be killed and eaten' on their cards, so Hannibal is out of a job." - http://cards.sf.net From sjudd at ffd2.com Fri Jul 21 16:23:47 2006 From: sjudd at ffd2.com (Steve Judd) Date: Fri, 21 Jul 2006 15:23:47 -0600 (MDT) Subject: [Slackers] Slang v1.4 released In-Reply-To: <20060719152433.C15121@artificial-stupidity.net> References: <20060719150920.B15121@artificial-stupidity.net> <20060719152433.C15121@artificial-stupidity.net> Message-ID: Yo Jaymz, > > Hey, I finally found some time for coding again :). Just a note, though - Cool! Now I need to find some! > Also, there seems to be a new bug in the parser, possibly relating to external > definitions - or at least, my use of them. I have a sprite.inc that looks > like: This sounds bad. I can't think of what it might be -- either array definitions or something I "improved" with subs (probably the latter). I'll have to get in and look. Phase errors are misleading. What happens is that the compiler assumes an address on the 1st pass -- usually a 16-bit address -- but on the second pass it turns out to be an 8-bit value. For example, lda blah sta $d021 blah = $fa will generate a phase error. Or, if an address changes, that will generate a phase error as well. Anyways, the point is that where the compiler catches a phase error is not really where the error is. I will try to get to these guys soon. -S From jaymz at artificial-stupidity.net Sun Jul 23 20:07:39 2006 From: jaymz at artificial-stupidity.net (Jaymz Julian) Date: Mon, 24 Jul 2006 11:07:39 +1000 Subject: [Slackers] Slang v1.4 released In-Reply-To: ; from sjudd@ffd2.com on Fri, Jul 21, 2006 at 03:23:47PM -0600 References: <20060719150920.B15121@artificial-stupidity.net> <20060719152433.C15121@artificial-stupidity.net> Message-ID: <20060724110739.I15121@artificial-stupidity.net> On Fri, Jul 21, 2006 at 03:23:47PM -0600, Steve Judd wrote: > Yo Jaymz, > > > > Hey, I finally found some time for coding again :). Just a note, though - > > Cool! > > Now I need to find some! Indeed, it can be hard in our modern lifestyle... le sigh. > > Also, there seems to be a new bug in the parser, possibly relating to external > > definitions - or at least, my use of them. I have a sprite.inc that looks > > like: > > Phase errors are misleading. What happens is that the compiler assumes an > address on the 1st pass -- usually a 16-bit address -- but on the second > pass it turns out to be an 8-bit value. For example, > > lda blah > sta $d021 > blah = $fa > > will generate a phase error. Or, if an address changes, that will > generate a phase error as well. Anyways, the point is that where the > compiler catches a phase error is not really where the error is. Oh, wow, that should never happen in the compiler part, I guess :) Thanks for the heads up --jj -- Jaymz Julian - Coder, Visionary, Fat Ass. "Hannibal is a serial killer. He only likes to kill and eat people. Very few people have `I want to be killed and eaten' on their cards, so Hannibal is out of a job." - http://cards.sf.net