Ideas I've been toying with

AerialX: Check your PM

So...
when are you going to release it? Also, a word processor(or atleast one as simple as notepad) and a file system explorer would be nice! On top of that, a terminal for the Wii would be awesome, so you wouldn't even need to write a program! Ofcourse, that's just me being hypothetical.

@strongfan:

AerialX found some major deficiencies with BSCRIPT, and I can't release it as is... (Well, I can, but it's almost useless).

Anyone wishing to try the version AerialX used, can go to the following URL

[drop.io]

There is no GOTO statement (a fundamental flaw)... and some other bits, but feel free to have a play.

pfft. GOTO statements are frowned upon anyway.

Quote
strongfan
pfft. GOTO statements are frowned upon anyway.

True, but when subroutines and GOTO statements are unsupported you have a fairly large problem.

If anyone wants to see my SnakeBASIC code for how I handled faking arrays and other things just ask :)



Edited 1 time(s). Last edit at 09/23/2008 01:19AM by AerialX.

Quote
strongfan
pfft. GOTO statements are frowned upon anyway.

I've heard that... but I cannot understand why... After all, they are how the CPU processes flow branches-

JMP 
 (standard jump)
JGE 
 (jump if comparison was greater than or equal to)

When you do your for( i=0; i < 2; i++ ) loop, all that does is at the end of the assembly is this-

for_start:

mov .....

cmp i, 2
jl for_start

It's because they make the code difficult to follow and understand. In ASM, you have no choice; the CPU itself has no concept of a subroutine (just copy PC to RA, goto address, and goto RA) and you're effectively limited to the instruction set provided. In higher-level languages you can do better.

out of curiosity, is that assembly?

In my post, yes. Intel x86

GOTO statements, I've read several books and all of them say to avoid the goto statement at all costs, it's often considered unstable, and is very easy to create hard to fun bugs in it. Easier solution is a switch case with a function at each case.

@HappyHacker:
Actually, that's not strictly true, at least with Intel x86 chips anyway. Intel chips have an opcode called "call" and an opcode called "ret" (Even the Commodore C64 MOS6510 had a JSR and RTS opcodes, which stand for "Jump to Subroutine", and "Return from Subroutine").

Call pushes the IP (Instruction Pointer) of the next instruction onto the stack, before setting the IP to the specified address of the subroutine.

The Ret opcode then pops the IP back from the stack (which is why it is important to always pop what you push in a subroutine), and return to the next statement after the call

@WiiPhlex:
Unstable?! WTF? That's a new one! lol, I've yet to see a jump statement not go to the address that was specified! And if there ever is such an occasion, that will be a problem with the compiler/interpreter, or the CPU is damaged!

I do admit there are certain choices of code which are more readable. But let's have a look at a compiled switch statement:

switch( argc )
{
  case < 2:
   printf("You must have at least two arguments");
   break;
  case 2:
  case 3:
   printf("Yay!");
   break;
  default:
   print("Too many arguments for me to handle");
   break;
}

Okay, now in assembler

 mov eax, argc
 cmp eax, 2
 jnl @case_generated_1
 push offset message_too_few_args
 call printf
 jmp @case_generated_4

@case_generated_1:
 cmp eax, 2
 je @case_generated_2
 cmp eax, 3
 jne @case_generated_3
@case_generated_2:
 push offset message_just_the_right_amount
 call printf
 jmp @case_generated_4

@case_generated_3:
 push offset message_too_many_args
 call printf

@case_generated_4:

So there you have it... several GOTOs in your switch statement.



Edited 1 time(s). Last edit at 09/24/2008 11:39AM by whodares.

How the switch is compiled can depend largely on the compiler, some change it to a series of if statements that point to an address that holds the 'executed code' for that case.

Ewwww.... that would be bad coding, and inefficient... Let's take a look...

switch_offsets:
case1  dd  offset @case_generated1
case2  dd  offset @case_generated2
case3  dd  offset @case_generated3

 ... code ...

 mov eax, argc
 cmp eax, 2
 jnl @case_generated_1skip
 call dword ptr [case1]
 jmp @case_generated_finish

@case_generated_1skip:
 cmp eax, 2
 je @case_generated_2okay
 cmp eax, 3
 jne @case_generated_2skip
@case_generated_2okay:
 call dword ptr [case2]
 jmp @case_generated_finish

@case_generated_2skip:
 call dword ptr [case3]

@case_generated_finish:

 ... code ...

;---------------------------------------- Subroutines
@case_generated1:
 push offset message_too_few_args
 call printf
 ret

@case_generated2:
 push offset message_just_the_right_amount
 call printf
 ret

@case_generated_3:
 push offset message_too_many_args
 call printf
 ret

If you think I have misconstrued your comment, please feel free to explain the your implementation of addressed subroutines as a switch.

But to me, this still requires jump statements (after calling any valid IF's, after all, you don't want it checking any of the other conditions after a "break;". But you also have the overhead of a lookup table, and you have additional returns from the subroutines, and you have extra data (return address) being pushed into the stack. Now the last of these is probably not such a big deal, unless your playing with recursive subroutines.

Simply put, if a compiler I used did a switch statement like that, I wouldn't use it any more... but then I like coding straight in assembler (well, for the PC at least, not really tried any assembler for the Wii) :-)

What I've seen in N64 games is jump tables (which are hopefully translated from switches); it translates to something like this:

void *PtrTable[] = {case1, case2and3, case2and3, case4};
if(Index > 3) goto casedefault;
goto PtrTable[Index];

case1:
//...
goto endswitch

case2and3:
//...
goto endswitch

case4:
//...
goto endswitch

casedefault:
//...
goto endswitch

endswitch:
//...

Not sure if that's syntactically valid, because I've never used gotos :) but that's about how it looks in the ASM. There's a pointer table, and it reads an address from there and jumps to it. It's not a function call, so they don't do the register saving and restoring you normally would. Basically you'll see a left-shift by 2 (to turn the index into a pointer), load word, jump to the register it just loaded to, and then several pieces of code one after another that just do one or two instructions and then all branch to the same place.



Edited 2 time(s). Last edit at 09/26/2008 01:57AM by HyperHacker.

You're code here actually wouldn't work. If argc/Index = 0, in my code it would print message_too_few_args, and in yours will call case1 (which is correct)...

If argc/Index = 1, it would still print message_too_few_args on mine (because the case statement is < 2), however, in your example it would go to case2and3

Okay, you could slip an extra case1 in the table to fix that problem, but when you expand this to work with a wider range, you'll soon find your memory being filed with these tables.

That said, if you have up to about 10 fixed options, this could possibly be used.

Quote
whodares
Intel x86

so, I'm assuming assembly is different for every computer. Dang!
wait- then how can programs be compiled at all if assembly is different for each computer?
EG: A program that is compatible with windows XP and Vista(like you would ever use vista anyway)

Yes, Assembly is different for each processor. Something assembled on an Intel x86 wouldn't run on ARM or PowerPC, neither any of the other ways round.

However, to have a language, like C, supported over several processors, you need to do one of two things

1. Create a "Virtual Machine", like JAVA... The byte code created by compiling JAVA will not run natively on any processor, however, for each processor, there is a VM which converts the JAVA byte code to the processor's byte code

or

2. You have several compilers (or compilers options), specifying which processor the application will be run on, so the binary can be produced in that format with the correct opcode set.

A program can run between XP and Vista for two reasons.
1. You're processor will still be an Intel (or compatible) chip
and
2. XP and Vista's executable binary format (called Portable Executable, PE for short), is supported by both operating systems.

You will find, that you can get 64bit windows applications, which are still PE files, but will not run on a 32bit install of XP. (There is a processor value stored in the PE header, describing the supported platform)

You could also, write an ELF loader for XP/Vista (though I'm not sure exactly how), which would load Windows programs that had been compiled into the ELF format... However, again, this would not mean that you could run Wii ELF files on your PC (because the processor is different), but the format would be supported.

Hope that makes sense



Edited 1 time(s). Last edit at 09/27/2008 01:29AM by whodares.