Re: ridiculous

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance


"Jon Skeet [C# MVP]" <skeet@xxxxxxxxx> wrote in message
news:MPG.215e65aaa4eafa194a4@xxxxxxxxxxxxxxxxxxxxxxx
Jon Slaughter <Jon_Slaughter@xxxxxxxxxxx> wrote:
Don't pass them, and just cast them. As for "who knows what they do" -
what exactly do you mean?

When you cast what actually goes on behind the scenes? Hell, for all I
know
they could box them and then unbox them or convert them all to ints then
to
bytes.

No, there's no boxing going on.


Yeah, I know.. I'm just saying that I don't know what there doing. I suppose
its not all that critical now but I guess I'm just kinda peaved that I spend
5 mins changing all those ints to bytes just to find it wouldn't work ;/
lol...

if it just used 32-bit registers then it wouldn't be a problem...

something like

mov eax, [some_byte]
and eax, 3
mov [some_byte], al

then it would be ok, but I have no idea what its trying to do.

Well, we don't know what the JITted code will do - but you can see what
the IL will do.

Yeah, I might take a look at that later if I need to... its not big deal
now.


I guess the problem is I'm wondering why it requires an explicit cast
from a
byte to an int?

It doesn't. It requries an explicit cast from an int to a byte. The
result of an operation involving two bytes is an int (in fact, the
individual bytes are promoted and then the operation is done on the
ints) and so you need to cast back down to byte.


(I meant int to byte)

But the result of the operations I'm using do not result in an int. Flitting
or changing bits in a byte don't result in an int. Right shifting also do
not result in an int... so there is absolutely no need to cast to an int in
anything I'm doing.

My code basically involves combining two bytes through a mask.

public void SyncSend(ParallelPortPins DataLines, int[] DataBits)
{
int m = (((int)DataLines) | (int)ClockPin) ^ ((int)InvertedPins);
int cp = ((int)ClockPin) ^ ((int)InvertedPins);
int clock = cp;


for (int k = 0; k < DataBits.Length; k++)
{
// Toggle ClockPin
clock = clock ^ cp;

DataBits[k] = (DataBits[k] & ~cp) ^ clock;

// Send data before clock
if ((((int)ClockPin) >> 16) > 0)
{
Data = (Data & ~m) | (DataBits[k] & m);
Control = ((Control & ((m >> 16) & 0xFF)) | ((DataBits[k] & m)
16)) ^ (clock >> 16);
} else
{
Control = ((Control & ((m >> 16) & 0xFF)) | ((DataBits[k] & m)
16)) ^ (clock >> 16);
Data = (Data & ~m) | (DataBits[k] & m);
}

Thread.SpinWait(DataRate);
}
}


Every bitwise operation involved never produces anything more than a byte.
(thats only one function, I have about 20 properties like

public int nSelectPrinter { get { control = Control; return (((control & 8)
3) & 1); } set { if (value >= 1) Control = Control | 8; else Control =
Control & (8 ^ 255); } }

and this is where I have problems when I use byte instead of int. But again,
its a waste to use an int yet if I use byte I get errors any time I use
bitwise operations and shifts.

But its just going to be easier for me to implement all this stuff in
unmanaged code because its much faster. But I still want to use C# for the
gui so I'll have to wrap it in managed C++ and that might offset the
benefit.


I suppose its actually not that big of a performance problem
but since I am going to have to write some unmanaged critical code I
might
as well move all that into it too.

If you can isolate it sensibly, that sounds reasonable.

Well, its mainly for some hardware communications stuff and I did some
tests
in unmanaged code and its 3x faster(basically the exact same code that
communicates with an unmanaged dll that hooks communicates with a kernel
mode driver).

In some cases 3x faster is worth it - in others it isn't. (That sounds
flippant, but if performance is already okay, it's often not worth
going unmanaged for the boost.) I assume in this case that it's worth
it though.


Well. I think in this case it will. I might also be able to improve it more
by working with a larger data path(actually could improve it by another
factor of 3). The parallel port itself cannot really write all that fast but
the faster I can get it less I have to worry about timing issues. (thats not
completely true but it just gives me more leeway)

It well might not be worth it though but I guess its a good experience to
play around with unmanaged and managed code.

Thanks,
Jon


.

Relevant Pages

  • Re: Newbie question about malloc
    ... "Implicit int" no longer exists in C. ... It's generally recommended to NOT cast the return from malloc. ... %d can never be the correct format specifier for a size_t. ... C99 introduced %zu for this purpose, ...
    (comp.lang.c)
  • Re: what will happen after i use free()???
    ... Inserting a cast before malloc is not needed, ... 56 bits while int is only 48 bits. ... So casting that value requires some ... Use cast only if you are absolutely sure that yor really needs the ...
    (comp.lang.c)
  • Re: about the array
    ... 3- If you cast to the wrong type by accident, ... are malloc and free. ... the compiler should issue a diagnostic - gcc ... unknown set of arguments, and return an int. ...
    (comp.lang.c)
  • Re: Simple Casting Question
    ... only in the form (int to float),,, ... or just casting identical types, so I hope that I can avoid some ... None of the conversions you describe ... In most cases where a cast is used, ...
    (comp.lang.c)
  • Re: ridiculous
    ... It requries an explicit cast from an int to a byte. ... communicates with an unmanaged dll that hooks communicates with a kernel ... I assume in this case that it's worth ...
    (microsoft.public.dotnet.languages.csharp)