Jump to content

Photo

XB Game Developers Package


436 replies to this topic

#426 OLD CS1 OFFLINE  

OLD CS1

    Technomancer

  • 5,862 posts
  • Technology Samurai
  • Location:Tallahassee, FL

Posted Tue Jan 8, 2019 10:46 PM

Am I to understand that this latest release is producing smaller or faster-running compiled code?



#427 LASooner OFFLINE  

LASooner

    Moonsweeper

  • 342 posts

Posted Wed Jan 9, 2019 4:16 AM

I believe the speed increase he mentioned is the compiler itself not the resulting compiled code



#428 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,328 posts
  • Location:Lansing, NY, USA

Posted Wed Jan 9, 2019 6:53 AM

I believe the speed increase he mentioned is the compiler itself not the resulting compiled code

That is correct. 

Now, with CPU Overdrive, the faster compiler, a cross assembler such as Asm99, and the assembly language loader, you can make changes to the XB program and test them very quickly.


Edited by senior_falcon, Wed Jan 9, 2019 8:04 AM.


#429 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,328 posts
  • Location:Lansing, NY, USA

Posted Thu Jan 10, 2019 10:13 PM

Good progress is happening with the CALL SUBPROGRAM in the compiler. The compiler does not produce proper code for this, but I can correct the source code file to the proper syntax. The runtime routines are written for this and, as expected, they work fine. I can call a named subprogram, pass values into the subprogram, change the values and pass them back to the calling program. Amazingly,it almost worked perfectly the first time. I had two INCs that should have been INCT.



#430 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,328 posts
  • Location:Lansing, NY, USA

Posted Sun Jan 13, 2019 9:26 PM

We all know the saying, "The sooner you start to code the longer the job will take."  I think the opposite is true as well: "The longer you take to start coding, the less time the job will take."

For 25 years I have avoided even trying to add named subprograms to the compiler because it seemed impossibly difficult. It turned out to be fairly straightforward, and It all works just like in XB. I thought having independent variables in the subprograms would be the hardest part but it turned out to need just a couple lines of code. Also there is no need for a second stack; I use the same stack used by GOSUB. Maybe if I had waited a hundred years it could have been done in 5 minutes or even less.

 

There is one step remaining: 10 CALL SUBTEST(A,(B),C) where the parentheses keep B from being updated. I can see a couple of ways to do this and am mulling over the best approach.

But even if that doesn't work out, you can get the same result with CALL SUBTEST(A,B+0,C) which works the same compiled and in XB.



#431 OLD CS1 OFFLINE  

OLD CS1

    Technomancer

  • 5,862 posts
  • Technology Samurai
  • Location:Tallahassee, FL

Posted Sun Jan 13, 2019 9:33 PM

"An object at rest cannot be stopped!"

 -- The Evil Midnight Bomber What Bombs at Midnight



#432 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,328 posts
  • Location:Lansing, NY, USA

Posted Yesterday, 7:04 AM

Here's a simple question. I think I know the answer, but want to be sure. It involves MOVing at an odd address:

MOV @>F001,R1

This moves the word at >F000 into R1. Is this always true? Can it ever move two bytes at >F001 and >F002 into R1 or the word at >F002?



#433 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,870 posts
  • Location:Silver Run, Maryland

Posted Yesterday, 7:32 AM

Here's a simple question. I think I know the answer, but want to be sure. It involves MOVing at an odd address:

MOV @>F001,R1

This moves the word at >F000 into R1. Is this always true? Can it ever move two bytes at >F001 and >F002 into R1 or the word at >F002?

 

I am nearly certain that the MOV instruction insures an even address boundary, likely by ANDing with >FFFE.  Edit: Actually, this is probably due to the fact that addressing is performed on a word basis, which, I suppose, could be thought of as the aforementioned ANDing.

 

...lee



#434 mizapf ONLINE  

mizapf

    River Patroller

  • 3,474 posts
  • Location:Germany

Posted Yesterday, 8:07 AM

Here's a simple question. I think I know the answer, but want to be sure. It involves MOVing at an odd address:

MOV @>F001,R1

This moves the word at >F000 into R1. Is this always true? Can it ever move two bytes at >F001 and >F002 into R1 or the word at >F002?

 

The 9900 has only 15 address bits (A0-A14), so the TMS9900 can only select even addresses. It is technically impossible for it to reach an odd address. The byte operations work like the word operations, but select the desired byte inside the ALU.



#435 TheBF OFFLINE  

TheBF

    Dragonstomper

  • 853 posts
  • Location:The Great White North

Posted Yesterday, 8:13 AM

 

I am nearly certain that the MOV instruction insures an even address boundary, likely by ANDing with >FFFE.  Edit: Actually, this is probably due to the fact that addressing is performed on a word basis, which, I suppose, could be thought of as the aforementioned ANDing.

 

...lee

 

I am a big fan of asking the machine.  :)

 

How could I do that quickly... hmmm...  Forth maybe?

 

In CAMEL99 Forth the store operator is:

MOV *R6+,*R4

So we can test this at the console.

Attached Files



#436 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • Topic Starter
  • 1,328 posts
  • Location:Lansing, NY, USA

Posted Yesterday, 8:51 AM

Excellent! This is handy as a flag when passing values to and from subprogram. Set the address odd if you don't want the variable to be updated when returning from the subprogram. When passing a value to the subprogram you can just ignore that it is odd and it will be passed normally. When passing a value back you can check whether it is odd and if so then don't pass it.

 

I guess the other question is whether any emulators do not behave this way.


Edited by senior_falcon, Yesterday, 8:53 AM.


#437 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 10,368 posts
  • Location:Hustisford, WI

Posted Yesterday, 11:10 AM

Heh.... that's pretty cool.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users