Chief Delphi - **FIRST EMAIL**/Java and Orbit Balls *****JAVA DISCUSSION***

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - **FIRST EMAIL**/Java and Orbit Balls *****JAVA DISCUSSION*** (http://www.chiefdelphi.com/forums/showthread.php?t=77418)

**FIRST EMAIL**/Java and Orbit Balls

Greetings Teams:

In the 2010 season, FRC teams will have the option of programming their robot in Java. The addition of Java as a programming language option is the culmination of work by Worcester Polytechnic Institute (WPI) and researchers from the Sun SPOT project at Sun Microsystems Laboratories. To learn more as you wait for the 2010 season to begin visit [ http://www.sunspotworld.com/frc/Welcome.html ]http://www.sunspotworld.com/frc/Welcome.html and [ http://first.wpi.edu/FRC/frc-programming.html ]http://first.wpi.edu/FRC/frc-programming.html.$@# We’ll be updating both locations as details are finalized.

If you are planning to hold an off season event or host a demonstration of your robot over the summer, you might want some extra game pieces. Used orbit balls (the ones that survived championship) are available for purchase starting today here [ http://logoloc.com/first/ ]http://logoloc.com/first/ Quantities are limited. If you are borrowing a FIRST field for your off season event, please remember that game pieces are not included in the loan.

Go Teams!

Re: **FIRST EMAIL**/Java and Orbit Balls

How much better is JAVA going to be than Lab view?

Is it easier to use?

Re: **FIRST EMAIL**/Java and Orbit Balls

Quote:

Originally Posted by Pjohn1959 (Post 859591)

How much better is JAVA going to be than Lab view?

Is it easier to use?

I think it is easier to make a fair comparison between C++ and Java than LabVIEW and Java. LabVIEW/[Java or C++] arguments are really more a matter of preference.

For FRC robotics, I prefer LabVIEW. For my neural-networks research, Java was the clear choice.

Re: **FIRST EMAIL**/Java and Orbit Balls

Yuck, java. The lack of pointers is a major turn-away for me.

However, for those high schools that offer AP computer science, the fact that the robot can now be programmed in java sorta bridges the learning gap a bit.

Re: **FIRST EMAIL**/Java and Orbit Balls

Quote:

Originally Posted by Uberbots (Post 859613)

What is it that you want to do with pointers that Java's pass by reference system can't do exactly?

Re: **FIRST EMAIL**/Java and Orbit Balls

Quote:

Originally Posted by Jared341 (Post 859640)

What is it that you want to do with pointers that Java's pass by reference system can't do exactly?

Pointer arithmetic. It can be useful if used properly. However, I wouldn't encourage students new to C++ to use pointer arithmetic on the robot, unless of course, you want them to experience the frustration of the dreaded "Seg Fault".

Re: **FIRST EMAIL**/Java and Orbit Balls

Quote:

Originally Posted by The Lucas (Post 859653)

Proper pointer arithmetic can result in small and efficient implementations of some data structures and algorithms, but given (a) the scope of a typical FIRST program and (b) the fact that we now have hardware and compilers that often get the job done just as fast and without the difficult-to-debug errors, I would probably expand "students new to C++" to "just about anyone without a really convincing reason". ::ouch:: :yikes:

Re: **FIRST EMAIL**/Java and Orbit Balls

Quote:

Originally Posted by The Lucas (Post 859653)

Code:

char *ptr = malloc(SIZE);

ptr + i is equivalent to &ptr[i]. Both cases boil down to just a load effective address instruction. Besides the obvious that Java hides the virtual address of all values in the symbol table, I don't see how you are missing anything by not being able to explicitly use pointer arithmetic. The point of pointer arithmetic is to compute the address of an element in an array. the "[]" operator retrieves that element and many people find this interface more intuitive. There is no performance advantage of using pointer arithmetic and there is nothing you can't do with the "[]" that you can do with pointer arithmetic (as the "[]" operator just encapsulates pointer arithmetic).

Re: **FIRST EMAIL**/Java and Orbit Balls

Quote:

Originally Posted by Chris27 (Post 859661)

Code:

char *ptr = malloc(SIZE);

ptr + i is equivalent to &ptr[i]. Both cases boil down to just a load effective address instruction. Besides the obvious that Java hides the virtual address of all values in the symbol table, I don't see how you are missing anything by not being able to explicitly use pointer arithmetic. in an array. the "[]" operator retrieves that element and many people find this interface more intuitive. There is no performance advantage of using pointer arithmetic and there is nothing you can't do with the "[]" that you can do with pointer arithmetic (as the "[]" operator just encapsulates pointer arithmetic).

[SIDE RANT] I think you are missing the point :D (sorry for the pun). The point of pointer arithmetic is to compute the address of an element (the array data structure is optional). If you can get that address by simply adding to a pointer (stored in a register) that is more efficient than computing that address by loading a symbol and adding the result of a multiplication (indexing an array using a variable).[/SIDE RANT]

I actually used a bit of pointer arithmetic this year to make a simple circular buffer for Camera Report Structures. Of course I could make a circular buffer class in Java too. Again, I am not recommending pointer arithmetic or saying it's vital, I am just saying it can be useful, simple and intuitive.

My real concern with Java is not the pointer stuff but rather the runtime performance. Java uses just in time (JIT) compilation and garbage collection which should add additional (non deterministic) load to the programs run (of course I need to read more about how theses features are implemented). That being said, I think additional language options are a good thing and all of my programing students are taught Java (not C) in high school for the AP exam.

Re: **FIRST EMAIL**/Java and Orbit Balls

Quote:

Originally Posted by The Lucas (Post 859726)

The efficiency is not what you suggest it is. Pointer arithmetic adds the result of a multiplication too: addition and subtraction are scaled by the size of the structure pointed to.

Re: **FIRST EMAIL**/Java and Orbit Balls

Quote:

Originally Posted by Alan Anderson (Post 859761)

The efficiency is not what you suggest it is. Pointer arithmetic adds the result of a multiplication too: addition and subtraction are scaled by the size of the structure pointed to.

But, at least in C, the size of the structure is a known quantity at compile time, so I would imagine that most of the time that multiplication can be eliminated by the compiler. And then on top of that, sometimes the multiplication will be by a power of 2, so the compiler will use a cheap shift operation.

Re: **FIRST EMAIL**/Java and Orbit Balls

Quote:

Originally Posted by The Lucas (Post 859726)

And as I stated in my earlier post, both cases boil down to a simple lea instruction in assembly

See, here is a small piece of code I just wrote.

Code:

 1 #include <stdlib.h>

 2 

 3 int main()

 4 {

 5   int *array = malloc(10 * sizeof(int));

 6   int *ptr;

 7   int i;

 8 

 9   for(i = 0; i < 10; i++)

10     ptr = array + i;

11 

12   return 0;

13 }

and its assembly

Code:

0000000000000000 <main>:

   0:        55                           push   %rbp

   1:        48 89 e5                     mov    %rsp,%rbp

   4:        48 83 ec 20                  sub    $0x20,%rsp

   8:        bf 28 00 00 00               mov    $0x28,%edi

   d:        e8 00 00 00 00               callq  12 <main+0x12>

  12:        48 89 45 f8                  mov    %rax,0xfffffffffffffff8(%rbp)

  16:        c7 45 ec 00 00 00 00         movl   $0x0,0xffffffffffffffec(%rbp)

  1d:        83 7d ec 09                  cmpl   $0x9,0xffffffffffffffec(%rbp)

  21:        7f 19                        jg     3c <main+0x3c>

  23:        8b 45 ec                     mov    0xffffffffffffffec(%rbp),%eax

  26:        48 98                        cltq   

  28:        48 c1 e0 02                  shl    $0x2,%rax

  2c:        48 03 45 f8                  add    0xfffffffffffffff8(%rbp),%rax

  30:        48 89 45 f0                  mov    %rax,0xfffffffffffffff0(%rbp)

  34:        48 8d 45 ec                  lea    0xffffffffffffffec(%rbp),%rax

  38:        ff 00                        incl   (%rax)

  3a:        eb e1                        jmp    1d <main+0x1d>

  3c:        b8 00 00 00 00               mov    $0x0,%eax

  41:        c9                           leaveq 

  42:        c3                           retq

Alternate code

Code:

 1 #include <stdlib.h>

 2 

 3 int main()

 4 {

 5   int *array = malloc(10 * sizeof(int));

 6   int *ptr;

 7   int i;

 8 

 9   for(i = 0; i < 10; i++)

10     ptr = &array[i];

11 

12   return 0;

13 }

its assembly

Code:

0000000000000000 <main>:

   0:        55                           push   %rbp

   1:        48 89 e5                     mov    %rsp,%rbp

   4:        48 83 ec 20                  sub    $0x20,%rsp

   8:        bf 28 00 00 00               mov    $0x28,%edi

   d:        e8 00 00 00 00               callq  12 <main+0x12>

  12:        48 89 45 f8                  mov    %rax,0xfffffffffffffff8(%rbp)

  16:        c7 45 ec 00 00 00 00         movl   $0x0,0xffffffffffffffec(%rbp)

  1d:        83 7d ec 09                  cmpl   $0x9,0xffffffffffffffec(%rbp)

  21:        7f 19                        jg     3c <main+0x3c>

  23:        8b 45 ec                     mov    0xffffffffffffffec(%rbp),%eax

  26:        48 98                        cltq   

  28:        48 c1 e0 02                  shl    $0x2,%rax

  2c:        48 03 45 f8                  add    0xfffffffffffffff8(%rbp),%rax

  30:        48 89 45 f0                  mov    %rax,0xfffffffffffffff0(%rbp)

  34:        48 8d 45 ec                  lea    0xffffffffffffffec(%rbp),%rax

  38:        ff 00                        incl   (%rax)

  3a:        eb e1                        jmp    1d <main+0x1d>

  3c:        b8 00 00 00 00               mov    $0x0,%eax

  41:        c9                           leaveq 

  42:        c3                           retq

Absolutely no difference whatsoever.

Re: **FIRST EMAIL**/Java and Orbit Balls

Quote:

Originally Posted by AustinSchuh (Post 859767)

This does not describe a difference between array indexing in Java and pointer arithmetic in C.

Re: **FIRST EMAIL**/Java and Orbit Balls

Quote:

Originally Posted by Alan Anderson (Post 859761)

The efficiency is not what you suggest it is. Pointer arithmetic adds the result of a multiplication too: addition and subtraction are scaled by the size of the structure pointed to.

Quote:

Originally Posted by AustinSchuh (Post 859767)

Quote:

Originally Posted by Chris27 (Post 859768)

And as I stated in my earlier post, both cases boil down to a simple lea instruction in assembly

See, here is a small piece of code I just wrote.

Code:

 1 #include <stdlib.h>

 2 

 3 int main()

 4 {

 5   int *array = malloc(10 * sizeof(int));

 6   int *ptr;

 7   int i;

 8 

 9   for(i = 0; i < 10; i++)

10     ptr = array + i;

11 

12   return 0;

13 }

and its assembly

Code:

0000000000000000 <main>:

   0:        55                           push   %rbp

   1:        48 89 e5                     mov    %rsp,%rbp

   4:        48 83 ec 20                  sub    $0x20,%rsp

   8:        bf 28 00 00 00               mov    $0x28,%edi

   d:        e8 00 00 00 00               callq  12 <main+0x12>

  12:        48 89 45 f8                  mov    %rax,0xfffffffffffffff8(%rbp)

  16:        c7 45 ec 00 00 00 00         movl   $0x0,0xffffffffffffffec(%rbp)

  1d:        83 7d ec 09                  cmpl   $0x9,0xffffffffffffffec(%rbp)

  21:        7f 19                        jg     3c <main+0x3c>

  23:        8b 45 ec                     mov    0xffffffffffffffec(%rbp),%eax

  26:        48 98                        cltq   

  28:        48 c1 e0 02                  shl    $0x2,%rax

  2c:        48 03 45 f8                  add    0xfffffffffffffff8(%rbp),%rax

  30:        48 89 45 f0                  mov    %rax,0xfffffffffffffff0(%rbp)

  34:        48 8d 45 ec                  lea    0xffffffffffffffec(%rbp),%rax

  38:        ff 00                        incl   (%rax)

  3a:        eb e1                        jmp    1d <main+0x1d>

  3c:        b8 00 00 00 00               mov    $0x0,%eax

  41:        c9                           leaveq 

  42:        c3                           retq

Alternate code

Code:

 1 #include <stdlib.h>

 2 

 3 int main()

 4 {

 5   int *array = malloc(10 * sizeof(int));

 6   int *ptr;

 7   int i;

 8 

 9   for(i = 0; i < 10; i++)

10     ptr = &array[i];

11 

12   return 0;

13 }

its assembly

Code:

0000000000000000 <main>:

   0:        55                           push   %rbp

   1:        48 89 e5                     mov    %rsp,%rbp

   4:        48 83 ec 20                  sub    $0x20,%rsp

   8:        bf 28 00 00 00               mov    $0x28,%edi

   d:        e8 00 00 00 00               callq  12 <main+0x12>

  12:        48 89 45 f8                  mov    %rax,0xfffffffffffffff8(%rbp)

  16:        c7 45 ec 00 00 00 00         movl   $0x0,0xffffffffffffffec(%rbp)

  1d:        83 7d ec 09                  cmpl   $0x9,0xffffffffffffffec(%rbp)

  21:        7f 19                        jg     3c <main+0x3c>

  23:        8b 45 ec                     mov    0xffffffffffffffec(%rbp),%eax

  26:        48 98                        cltq   

  28:        48 c1 e0 02                  shl    $0x2,%rax

  2c:        48 03 45 f8                  add    0xfffffffffffffff8(%rbp),%rax

  30:        48 89 45 f0                  mov    %rax,0xfffffffffffffff0(%rbp)

  34:        48 8d 45 ec                  lea    0xffffffffffffffec(%rbp),%rax

  38:        ff 00                        incl   (%rax)

  3a:        eb e1                        jmp    1d <main+0x1d>

  3c:        b8 00 00 00 00               mov    $0x0,%eax

  41:        c9                           leaveq 

  42:        c3                           retq

Absolutely no difference whatsoever.

Since I'm done my work for the day, I'll continue this rant. What I (and I think Austin too) am getting at is this example (in same style as Chris' examples):

Code:

 1 #include <stdlib.h>

 2 

 3 int main()

 4 {

 5   int *array = malloc(10 * sizeof(int));

 6   int *ptr = array;

 7   int i;

 8 

 9   for(i = 0; i < 10; i++)

10     ptr++;

11 

12   return 0;

13 }

That is different and removes the need for the shift left op (since as Austin said the sizeof(int) is known at compile time and can just be added). Cant do that without explicit pointers. If the multiplication by type size is bothersome you can use an unsigned int and typecast it to a pointer. Also useful if you have an array of structs and are only working with same element in each struct (you can just add the size of the struct to the pointer).

Plus explicit pointers make functions like swap (commonly used in bubblesort simple) simpler using C pass by reference. Again not vital, just something that gets abstracted away in a higher level language.

Re: **FIRST EMAIL**/Java and Orbit Balls

Quote:

Originally Posted by The Lucas (Post 859797)

Since I'm done my work for the day, I'll continue this rant. What I (and I think Austin too) am getting at is this example (in same style as Chris' examples):

Code:

 1 #include <stdlib.h>

 2 

 3 int main()

 4 {

 5   int *array = malloc(10 * sizeof(int));

 6   int *ptr = array;

 7   int i;

 8 

 9   for(i = 0; i < 10; i++)

10     ptr++;

11 

12   return 0;

13 }

I don't understand the point (!) of your example. What part of it should I focus on? None of it appears to show me a reason for preferring to use explicit pointers.

Quote:

Plus explicit pointers make functions like swap (commonly used in bubblesort simple) simpler using C pass by reference...

Isn't pass by reference exactly what Java lets you do in such cases? I guess I'm completely failing to understand what you're trying to explain here.