Re: CoreWars issues
> [Bytes vs Bits?]
>
> Martin, I'm not sure what [any of us] mean by a btye, but here's my
> definition:
Call me old fashioned, but I think a byte is 8 bits. I know! I'm a stick in
the mud! But I think it might be easier all round.
> 12099960044 - this is not a byte, this is a complete instruction
we agree
> 4 - this *is* a byte, a part of the instruction
Looks like a digit to me 
>
> Every full instruction is 11 bytes long.
Seems like a lot to me 
> Here's the breakdown:
>
> opcode: 1 byte (0-9)
only 10 opcodes
> 1st operand mode: 1 byte (0-2)
> 2nd operand mode: 1 byte (0-2)
> 1st operand: 4 bytes (0000-9999)
only 10000 possible values
> 2nd operand: 4 bytes (0000-9999)
But what if we did this:
opcode = 4 bits - This allows space for 16 opcodes, not the 10 you have now
1st op mode = 2 bits - This allows for 4 modes, but we only need 3
2nd op mode = 2 bits - This allows for 4 modes, but we only need 3
Number of bits in opcode and modes = 8 = 1 byte.
So opcode and modes are all stored in 1 byte, but give room for all the
corewars opcodes.
1st operand = 2 bytes - This allows integer values 0 - 63535.
2nd operand = 2 bytes - This allows integer values 0 - 63535.
So the whole instruction, opcode, modes and operands are all carried in 5
bytes with room to grow, where the way it works now an instruction takes 11
bytes, and already you're running out of namespace.
Notice too that the opcodes + the modes end up giving a separate value for
each possible combination of opcode and modes. It probably wouldn't be too
hard to massage that into something that would run through the instruction
interpreter that Rod has already made. And we could probably find low-level
bit operations that would make the massaging process really fast.
Anyway - I'll write up a few routines to handle this and see what you think.
Honest - this isn't a quagmire
(what was that sucking sound?)
Bye
Martin
>
> Probably not the best naming convention, but oh well :)
>
> A feature my CWC prototype includes is 2-byte opcodes. This overcomes the
> 10 opcode limit imposed by having it as 1 byte. So the instruction:
>
> 12099960044 (1-2-0-9996-0044) -- 11 bytes long
>
> using 2 byte opcodes would translate to:
>
> 012099960044 (01-2-0-9996-0044) -- 12 bytes long
>
> Of course, in order for it to work with Rod's CW he'll have to code
> support for it into his math routines. My prototype compiler still
> handles
> 1 byte opcodes (by default); to compile to 2-byte you use a commandline
> flag.
> Maybe Rod can handle 2-byte using a flag too?
>
>
> >I assumed that a 10000 location memory core was equivalent to 10000
> >bytes. Not so! The memory core has room for 10000 instructions, but
> each
> >instruction has at least 5 bytes, so the core is really 50000 bytes
> >addressable in 5 byte chunks.
>
> I can see where you're coming from on this one...
>
> 12099960044 -- 11 bits = 1 byte
> 4 -- 1 bit = 1/11 byte
>
> Maybe we should make a standard way of referring to compiled data? I
> would
> prefer [my interpretation of?] Martin's method.
>
> I know the feeling Martin: from looking at Rod's code, I first thought
> that
> each bit of an instruction was a sequence element. After I ran through it
> with
> trace on, I realized that each _byte_ (full instruction) occupied a
> sequence element. Sometimes it's hard to figure out how internal data is
> stored just by looking at the
> code :)
>
>
>
> [Instruction Storage In-Core]
>
> >personally, I don't think it's a good idea (storing a complete
> instruction):
> >
> > a) It gets too far away from the Corewars that the rest of the world
> plays.
> > b) There is quite a bit of overhead involved in translating the big
> numbers
> > into instructions, and moving them around... for a display.
> > c) Besides getting away from corewars, this virtual machine gets away
> from
> > being like a computer too.
>
> Well, sofar there's two ways to do it:
>
> 1. Store each bit of an instruction in one sequence element. Basically a
> full
> instruction is 11 elements long ( or CORE[FirstBit..FirstBit+11] ).
>
> Pros:
> There's no need for any parsing functions to separate the different
> bits.
>
> Cons:
> The Core sequence gets 11x larger, possibly causing slowdowns.
>
> 2. Store each full instruction in one sequence element (the current
> method).
>
> Pros:
> Keeps the Core down to a decent size, and init'ing the Core to
> CORESIZE
> only requires repeat(0, CORESIZE) and not repeat(0, CORESIZE * 11)
> (not that it matters much :)
>
> Cons:
> Requires a routine to do bit munging before operating on an
> instruction,
> possibly causing slowdowns (like Martin mentioned).
>
>
> Personally, I favor the 2nd method, because although it does need some
> intermediate parsing of the numbers, it takes up less space overall, and
> what
> would you rather have: sequence size overhead or a little routine
> overhead?
>
> The original idea of CoreWars was to act like an abstracted computer
> system,
> but since we've gone so far from the norm anyway, why not stay in that
> direction?
>
>
> Thus endeth my comments for today,
>
> ----->Buddy
> budmeister1 at juno.com
>
|
Not Categorized, Please Help
|
|
