Ideas I've been toying with

Re: Ideas I've been toying with

whodares — Sat, 27 Sep 2008 01:26:26 +0200

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

Re: Ideas I've been toying with

strongfan — Fri, 26 Sep 2008 22:52:35 +0200

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)

Re: Ideas I've been toying with

whodares — Fri, 26 Sep 2008 10:40:55 +0200

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.

Re: Ideas I've been toying with

HyperHacker — Fri, 26 Sep 2008 01:55:41 +0200

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.

Re: Ideas I've been toying with

whodares — Thu, 25 Sep 2008 17:43:04 +0200

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) :-)

Re: Ideas I've been toying with

WiiPhlex — Thu, 25 Sep 2008 16:00:33 +0200

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.

Re: Ideas I've been toying with

whodares — Wed, 24 Sep 2008 11:31:34 +0200

@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.

Re: Ideas I've been toying with

WiiPhlex — Wed, 24 Sep 2008 10:31:42 +0200

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.

Re: Ideas I've been toying with

whodares — Wed, 24 Sep 2008 09:08:32 +0200

In my post, yes. Intel x86

Re: Ideas I've been toying with

strongfan — Tue, 23 Sep 2008 21:22:33 +0200

out of curiosity, is that assembly?

Re: Ideas I've been toying with

HyperHacker — Tue, 23 Sep 2008 17:50:25 +0200

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.

Re: Ideas I've been toying with

whodares — Tue, 23 Sep 2008 10:16:27 +0200

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

Re: Ideas I've been toying with

AerialX — Tue, 23 Sep 2008 01:18:43 +0200

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 :)

Re: Ideas I've been toying with

strongfan — Mon, 22 Sep 2008 23:44:47 +0200

pfft. GOTO statements are frowned upon anyway.

Re: Ideas I've been toying with

whodares — Sun, 21 Sep 2008 01:05:30 +0200

@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.

Re: Ideas I've been toying with

strongfan — Tue, 16 Sep 2008 01:13:44 +0200

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.

Re: Ideas I've been toying with

whodares — Sun, 07 Sep 2008 23:34:57 +0200

AerialX: Check your PM

Re: Ideas I've been toying with

AerialX — Sun, 07 Sep 2008 17:34:56 +0200

Quote
whodares
Well, as you can see from the posted code example, I had to have for/next loops to slow down the scrolly bit at the end :-) It runs really fast.

I might open it up for a few people for testing if anyone is interested. It would also give chance to hear other peoples opinions on it's performance, and may indicate areas where it's weak etc.

I'll help test it for you :)
When I go to test a new platform it's my tradition to make a console snake game. I used it to judge Java performance on the DS once, writing the exact same game in C and Java (the result was that Java ran at about 60% the speed of the C version).

Quote
whodares
If I didn't have quite so many projects on the go, I would definately work with you on that! Would actually probably be beneficial to me, being a .NET developer. If you do take on this task, and need help, drop me a pm/mail. I'm not sure how much time I'll be able to give you, but I'll see what I can do

As much as I'd like to, it'd be a huge project and I also have my own projects I'm already working on. Maybe one day, but I doubt I'll get time to work on it anytime soon.

Re: Ideas I've been toying with

whodares — Sun, 07 Sep 2008 17:07:51 +0200

The IDE will definately be on the Wii...

The compiler (if I get around to writing one) will have to be sat on the PC though, to take advantage of libogc, GRRLib, Wiiuse, etc. In fact, it would probably be more of a source code converter to convert the BASIC script to C for compiling.

That type of compiler might also assist peoples learning of C syntax, when they can relate it to the BASIC applications they've produced.

Re: Ideas I've been toying with

strongfan — Sun, 07 Sep 2008 15:09:13 +0200

lol. I expected that. Oh well. Be sure to include a compiler in the IDE... and make sure the IDE is actually ON the Wii! Also, from now on it is required that every thing on the Wiibrew scene is programmed in BASIC from here on out!

Re: Ideas I've been toying with

whodares — Sat, 06 Sep 2008 22:22:22 +0200

@Arikado: Why would they wait when they can use their favourite text editor to create the file to stick on the SD card. But either way, they'll need to wait for a release anyway ;-)

@strongfan: At present there are no plans to, I haven't even designed the graphics extensions to the language yet.
I'm not actually sure if will be a help anyway, the language isn't event based (by design, but that doesn't mean you couldn't alter it), and as such, there are no widgets/controls.

To be honest, I'm not planning on taking this project any futher than a simple IDE and a language which supports most Wii features. The whole project will be open source with a GNU license (or basically what BSCRIPT had), so if you wanted to add a windowing layer to the language and a GUI editor to the IDE, you'd be free to do so.

Re: Ideas I've been toying with

strongfan — Sat, 06 Sep 2008 20:01:10 +0200

And while you're at it, do you think you can get a GUI generator running, like Visual BASIC?

Re: Ideas I've been toying with

Arikado — Sat, 06 Sep 2008 16:40:54 +0200

Congratulations whodares. But I won't worry about an influx of bad programs until you get an IDE up. That will surely take more than an evening.

Re: Ideas I've been toying with

whodares — Sat, 06 Sep 2008 09:54:49 +0200

Quote
AerialX
How's the performance? At least I didn't see any breaks in the lines you drew; have you tried putting it to the test against C/C++?

Well, as you can see from the posted code example, I had to have for/next loops to slow down the scrolly bit at the end :-) It runs really fast.

I might open it up for a few people for testing if anyone is interested. It would also give chance to hear other peoples opinions on it's performance, and may indicate areas where it's weak etc.

Quote
AerialX
I guess this means I'm free to try to port the Mono monster myself :)

If I didn't have quite so many projects on the go, I would definately work with you on that! Would actually probably be beneficial to me, being a .NET developer. If you do take on this task, and need help, drop me a pm/mail. I'm not sure how much time I'll be able to give you, but I'll see what I can do

Re: Ideas I've been toying with

daniel_c_w — Sat, 06 Sep 2008 04:23:55 +0200

Quote
strongfan
at least BASIC isn't as hard as
#include 
int main(){
cout >> "Hello world!  This is more work than there needs be!";
return 0;
}
Only to find the console window just flashes at you, then you have to say

[...]

Moral of this story:
make them learn a language easier than C++.

That's not a problem of the language (c or c++).
You are having problems with the library and the the operarting system.
A simple Print statement in Qbasic might "flash" as you as well.

Re: Ideas I've been toying with

AerialX — Sat, 06 Sep 2008 02:55:55 +0200

Quote
whodares
And that's one evening!

Okay, there's no IDE, but it runs code loaded off the SD Card, and supports the Wiimote in IR mode

Wow, that's great. Nice demo, too. How's the performance? At least I didn't see any breaks in the lines you drew; have you tried putting it to the test against C/C++?

I guess this means I'm free to try to port the Mono monster myself :)

Re: Ideas I've been toying with

WiiPhlex — Sat, 06 Sep 2008 01:57:37 +0200

Quote
strongfan
at least BASIC isn't as hard as
#include 
int main(){
cout >> "Hello world!  This is more work than there needs be!";
return 0;
}
Only to find the console window just flashes at you, then you have to say
#include 
#include(cstdio);
int main(){
cout >> "Hello world!  This is more work than there needs be!";
return 0;
system "Pause";
}
Only to find your simple hello world program is incompatible with the Wii because you used
system "Pause";
Moral of this story:
make them learn a language easier than C++.

lolololololol There's literally hundereads of ways of doing that. As for compatability on the wii, you just need a little thinking, a while true loop for example that prints that to the screen..

Re: Ideas I've been toying with

whodares — Sat, 06 Sep 2008 01:54:56 +0200

Quote
Arikado
Too complicated. Its all just talk. There's no way whodares will pull it off "by the end of the weekend"

Urm, check this out...
http://wiibrew.org/wiki/User:Whodares/WiiBASIC

And that's one evening!

Okay, there's no IDE, but it runs code loaded off the SD Card, and supports the Wiimote in IR mode

Re: Ideas I've been toying with

Arikado — Fri, 05 Sep 2008 23:59:51 +0200

system "Pause"; isn't the (only) reason that doesn't work.

Re: Ideas I've been toying with

strongfan — Fri, 05 Sep 2008 22:42:47 +0200

at least BASIC isn't as hard as

#include 
int main(){
cout >> "Hello world!  This is more work than there needs be!";
return 0;
}

Only to find the console window just flashes at you, then you have to say

#include 
#include(cstdio);
int main(){
cout >> "Hello world!  This is more work than there needs be!";
return 0;
system "Pause";
}

Only to find your simple hello world program is incompatible with the Wii because you used

system "Pause";

Moral of this story:
make them learn a language easier than C++.