Difference between revisions of "User:Miked0801"
(Quick hello world, I'm still alive :))
(hey hey hey!)
|Line 50:||Line 50:|
--[[User:Miked0801|Miked0801]] 21:51, 17 December 2015
--[[User:Miked0801|Miked0801]] 21:51, 17 December 2015
Revision as of 21:07, 30 December 2015
I'm primarily a nano-bot author as that is where my passions lie. I'm still active in creating new bots along with helping anyone I can. Below are my current bots.
Uh oh, I think I just figured out how to completely cheat the codesize thing. I could probably fit all of Toorkild's code into a nanobot. How? Running Java Byte code from a static buffer. Take any robot's byte code and drop it statically into an array/string/whatever. Array values do not count towards size. Write a routine that jumps the code pointer into the array. You are now running a nearly infinite amount of code without a major size hit. I could probably write a bot like this in an evening if I really wanted to cheat and win this badly. Thoughts? --Miked0801 01:02, 28 May 2009 (UTC)
- Oy! Not sure how we'd deal with that. I wonder if Robocode's classloaders could prevent this from happening? Or the code size utility produce some kind of "N/A" code size for classes that do this? --Voidious 02:56, 28 May 2009 (UTC)
- I'm fairly sure the Robocode security manager wouldn't allow this, I once tried using Java Reflection and the security manager disabled my bot immediately. However, if it is possible, I think we should either 1) modify the Codesize util so it looks for bytecode in strings as well or 2) fix the security manager so that it isn't possible to jump the code pointer into a static buffer. But why don't you try it and see if it works =) --Skilgannon 09:19, 28 May 2009 (UTC)
- Er, I'm 90% sure that jumping the code pointer into a string or array, is completely impossible in java bytecode in the first place. I'm pretty sure that program memory and data memory are considered comletely seperate in the VM... So all this to do with the classloaders/security managers/codesize util is unnecessaary... --Rednaxela 12:45, 28 May 2009 (UTC)
- I don't think this is impossible with either javac or Jikes, but how about Jasmin you are working on, Rednaxela? I'm quite sure we can do that in assembly, but not sure with Java assembly. » Nat | Talk » 13:02, 28 May 2009 (UTC)
- In machine code for x86 or ARM or most other physical architectures, that is possible, but java bytecode follows a different model. In most physical architectures, "program memory" and "data memory" are the same thing, so one can use the same memory for both purporses. The Java VM follows a different architecture pattern, where "program membory" and "data memory" are seperate and no bytecode instruction has a parameter that can refer to either, only one. (By the way, I'm pretty sure you meant to say "I think this is impossible" or "I don't think this is possible". Only need one negative :)) --Rednaxela 13:10, 28 May 2009 (UTC)
Next Codesize question :) - Is there any way to tell the compiler that you no longer a paramter and to use that register for a local var? That's free bytes if you can do it. --Miked0801 23:39, 28 May 2009 (UTC)
- With javac/jikes? No. With an assembler for java bytecode? Sure! ;) --Rednaxela 23:49, 28 May 2009 (UTC)
- Bah, I program in dozens of asm languages already. One more wouldn't be hard. Of course the source file would no longer compile... --Miked0801 00:59, 29 May 2009 (UTC)
- Hi Mike, congrats on getting LittleBlackBook to the top. I was surprised my Neophytes lasted as long as they did. LBB is a very sneaky concept and impressively scrunched into nanosize. I especially like the way you index into the beginning of the GF string to add custom movement. I thought of using a string buffer for bytecode way back. I had a few tries playing with the classloader and got the concept to work in isolation, but the securitymanager would not permit it to run in robocode. Didn't try very hard though, so not totally sure. --JohnCleland 21:44, 22 October 2009 (UTC)
- Thanks for the kind words :) --Miked0801 19:04, 18 January 2010 (UTC)
I come back here every now and then and am always impressed to see things humming quietly along. When I first started my nano adventure, it was while staying up late watching and helping to feed my infant daughter. I was a wide eyed game programmer with some extra time. Now, a father of 3 with my eldest approaching high school, this site and hobby helps me to reflect on just how far things have come here. Getting LBB tuned required more computer processing power than I had at the time, so I occasionally used a "few" computers at my place of employment late at night to run all the tables. Now, my home system could probably chew through the calcs by itself it the same amount of time. I always promise myself that I will spend a week here or there getting LBB or Moebius whipped back into shape, but life has other ideas. So, I will continue to stop by every now and then, I will tune LBB here or there as I can, and I will continue to enjoy watching people discover this awesome little distraction that we have poured so much effort into. --Miked0801 10:59, 23 August 2014 (UTC)
Another year or so has passed and I still grin to see my DustBunny doing its thing. Thanks to the author who fixed up LittleBlackBook's tables. A fun idea that went way to far. I'm still working in the game industry after all these years. Found this page by accident after a bit of time and had some nice memories. Keep things humming!
--Miked0801 21:51, 17 December 2015