Can you knock my socks off ? Can you mimic Skybuck's/Delphi's Major Breakthrough for code path and memory structure selection ?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Can you knock my socks off ? Can you mimic Skybuck's/Delphi's Major Breakthrough for code path and memory structure selection ?

Skybuck Flying
Hello,

This usenet posting discussess what I consider to be a major breakthrough
for me and Delphi coding in general.

It explains what I need and want to do and how I solved it.

So instead of typing the whole idea again I simply copy and paste what I
posted back then on this mailing list plus the features the code uses:

New Delphi 2007 Features used:

"methods in records"

"properties in records"

Later I even used "class method in records" but not discussed below.

Old features used:

"variant types/records or whatever"

"case statements used to switch code paths"

"pointers used to switch memory structures/layouts"

"typecasts used to access fields from raw/untyped pointer"

None the less very interesting example.

Problem is ofcourse FPC does not support the new Delphi 2007 features.

And the big question is how would you port this code to FPC ?

My bet is it would drive you crazy because you can't get it to work.

And if you can your code will probably be ugly and huge ?

Can you prove me wrong ? and knock my socks off ?

Original posting from meeeee:

"
Hello,

Seperating record storage from record handling was a good and nice idea (I
knew it all along lol)

This garantuees:

1. Compactness of the record/storages.

2. No gaps

3. Adding "handling" fields can be done to the handling records... so these
fields aren't transmitted to save bandwidth which is good.

4. Nice seperation of handling code.

5. Flexiblity, selecting structure based on bitmode is now possible.

6. Internal handling of largest supported type is possible and includes ZERO
PERFORMANCE HIT to program... especially once delphi goes 64 bit.
(For now there is a small performance hit because uint64 type is emulated)

7. Finally only a little performance hit by reading and writing finally.
Which is neglectiable.

8. Also bitmode can be set once and is remember. Isn't transmitted...
ofcourse for a protocol a "info" packet could be sent once to inform the
other side of the bitmode ;)

9. And finally as already mentioned... the program can now write code pretty
much just once, high performant by simply using the natives types as
provided by the handling code.

10. No stupid properties... Actually those properties causes some weird
const/compiler problems... so that wasn't even possible.

(So fields need to be direct not via properties.)

11. And most important: Internal number can be passed to var parameters !
EXCELLENT

See code for example which might be more clear then this wacky explanation
above LOL.

Brilliant piece of code if I say so myself.

This is definetly usuable and actually will increase the performance of my
code !

NEAR ZERO PERFORMANCE HIT...

Just need a read once and write once... LOVELY

And can code it just once LOL LOVELY !

MAXIMUM COMPACTNESS

NO GAPS

LOVELY ;)

// *** Begin of Code ***

program ProjectSelectingStructureV6;

{$APPTYPE CONSOLE}

{

Selecting a Structure Idea

Version 0.01 created on 10 oktober 2007 by Skybuck Flying

I wish I could select a structure based on a variable.

Example code below.

There must be no compiler generated gaps in the structures, that would cost
space !
That's why the structures are "packed" to save space !

See *** below for feature idea.

Some success with code below

No gaps, A nice property, modest code overhead.

Probably still can't be passed as var parameters..

But this solves 50% of the problem.

My comments from the usenet:

The following code solves 50% of the problem.

Internally the program can work with the largest integer type available.

When the programs needs to read or write to the packet it can specify the
bit mode.

Only those bits will be read or written to/from the packet no ovewrites
should occur.

Only problem remains is the property Number can not be passed to var
parameters.

At least now the programmer can write single lines of code and not used case
statements anymore in maybe 50% of the time ;)

}


{

version 0.06 created on 11 oktober 2007 by Skybuck Flying !

One might call this a major breakthrough ! ;)

All problems now solved.

Selecting structures based on bit mode is now possible...

It's even done only once, only when bitmode is set/changed.

By using NumberRead, NumberWrite... the internal storage Number can be read
or written
to the real package.

The internal storage number simply called "Number : Uint64"... can be used
to do internal program coding.

The storage/internal/temp 64 bit number can be passed as a var parameter so
this solves that problem as well !

All problems now 100% solved and performance further increased ;) especially
when bit mode only has to be set a few times or so ;)

Also the storage structures and the handling code is nicely seperated.

Some extra fields in the handling code requires a little bit more memory...
but the storage
remains compact and gap free ! ;)

Simply call NumberWrite... if the number is to be written to the package...

This could be done at a final stage right before sending the package.

Also reading would have to be done only once etc...

And working with uint64 directly is pretty fast... SO NO PERFORMANCE HIT
what so ever !

EXCELLENT

}


uses
  SysUtils;

type
 TbitMode = ( bm_8, bm_16, bm_32, bm_64 );

type
 // storage
 Pheader8bit = ^Theader8bit;
 Theader8bit = packed record
  mNumber : byte;
  mLength : word;
 end;

 Pheader16bit = ^Theader16bit;
 Theader16bit = packed record
  mNumber : word;
  mLength : word;
 end;

 Pheader32bit = ^Theader32bit;
 Theader32bit = packed record
  mNumber : longword;
  mLength : word;
 end;

 Pheader64bit = ^Theader64bit;
 Theader64bit = packed record
  mNumber : uint64;
  mLength : word;
 end;

 TpacketStorage = packed record
  case TbitMode of
   bm_8 : ( Header_8_bit : Theader8bit; ); // must use different names for
header
   bm_16 : ( Header_16_bit : Theader16bit; );
   bm_32 : ( Header_32_bit : Theader32bit; );
   bm_64 : ( Header_64_bit : Theader64bit; );
 end;

 // handling code:

 TheaderHandling = record
 private
  mBitMode : TbitMode;
  mHeaderPointer : pointer;
 public
  Number : uint64;

  procedure NumberWrite;
  procedure NumberRead;
 end;

 // handling
 TpacketHandling = record
 private
  mBitMode : TbitMode;
  mPacketStorage : TpacketStorage;

  procedure SetBitMode( ParaBitMode : TbitMode );
 public
  Header : TheaderHandling;
  property BitMode : TbitMode read mBitMode write SetBitMode;
 end;

// set header pointer just once :) for further use ;)
procedure TpacketHandling.SetBitMode( ParaBitMode : TbitMode );
begin
 mBitMode := ParaBitMode;
 Header.mBitMode := ParaBitMode;

 case ParaBitMode of
  bm_8 :
  begin
   Header.mHeaderPointer := @mPacketStorage.Header_8_bit;
  end;

  bm_16:
  begin
   Header.mHeaderPointer := @mPacketStorage.header_16_bit;
  end;

  bm_32:
  begin
   Header.mHeaderPointer := @mPacketStorage.header_32_bit;
  end;

  bm_64:
  begin
   Header.mHeaderPointer := @mPacketStorage.header_64_bit;
  end;
 end;
end;

procedure THeaderHandling.NumberWrite;
begin
 case mBitMode of
  bm_8:
  begin
   Pheader8bit(mHeaderPointer).mNumber := byte(Number);
  end;

  bm_16:
  begin
   Pheader16bit(mHeaderPointer)^.mNumber := word(Number);
  end;

  bm_32:
  begin
   Pheader32bit(mHeaderPointer)^.mNumber := longword(Number);
  end;

  bm_64:
  begin
   Pheader64bit(mHeaderPointer)^.mNumber := uint64(Number);
  end;
 end;
end;

procedure THeaderHandling.NumberRead;
begin
 case mBitMode of
  bm_8:
  begin
   Number := Pheader8bit(mHeaderPointer).mNumber;
  end;

  bm_16:
  begin
   Number := Pheader16bit(mHeaderPointer).mNumber;
  end;

  bm_32:
  begin
   Number := Pheader32bit(mHeaderPointer).mNumber;
  end;

  bm_64:
  begin
   Number := Pheader64bit(mHeaderPointer).mNumber;
  end;
 end;
end;

procedure Test( var ModifyMe : Uint64 );
begin
 ModifyMe := 258;
end;

var
 vPacket : TpacketHandling;
begin
 try
  // set packet mode just once ;)
  vPacket.BitMode := bm_8;

  // write a number to the packet in it's bit mode ;)
  vPacket.Header.Number := 257;
  vPacket.Header.NumberWrite;

  // read what was stored ;)
  vPacket.Header.NumberRead;
  writeln( vPacket.Header.Number );

  // read number
  vPacket.Header.NumberRead; // not really necessary but let's do it anyway
;)
  Test( vPacket.Header.Number );
  vPacket.Header.NumberWrite;

  // read number and show it
  vPacket.Header.NumberRead;
  writeln( vPacket.Header.Number );

 except
  on E : Exception do
  begin
   writeln( e.Message );
  end;

 end;

 readln;
end.

// *** End of Code ***

Bye,
  Skybuck.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Can you knock my socks off ? Can you mimic Skybuck's/Delphi's Major Breakthrough for code path and memory structure selection ?

Peter Vreman
> None the less very interesting example.
>
> Problem is ofcourse FPC does not support the new Delphi 2007 features.
>
> And the big question is how would you port this code to FPC ?

Please don't make _your_ problem our problem!!!

You knew beforehand that FPC doesn't support these features. If you want
to be compiler independent you have to keep to the smallest feature set.

Writing multiple mails with complains will not help to get features in
the compiler.

Peter
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Can you knock my socks off ? Can you mimic Skybuck's/Delphi's Major Breakthrough for code path and memory structure selection ?

Skybuck Flying
In reply to this post by Skybuck Flying
Ok, this morning I thought about it and maybe that will work.

(I also just tried it, and it seems to work for now !)

However what about the future, what if Tobject is dropped ?

It probably will not happen because Tobject seems pretty important.

Objects can have properties too.

Only little remaining problem is no class methods ?

I shall try the code out with objects and see what happens etc ;)

Thanks to all for replieing,
  and
    Bye,
      Skybuck.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Can you knock my socks off ? Can you mimic Skybuck's/Delphi's Major Breakthrough for code path and memory structure selection ?

Skybuck Flying
In reply to this post by Peter Vreman
It's not really a problem so far it seems.

Simply replace record with object and it will work and compile at least in
Delphi.

I haven't tried FPC yet... but if it wouldn't compile that would be amazing
and a problem.

None the less, the example remains interesting.

It describes a general problem:

How to switch between data structures/layouts and still use more or less the
same code,  could be different code underwater, for the programmer it must
look the same.

The example does just that. It always the programmer to work with 64 bit
integers, and finally it can write them and read them as any other kind of
integer or data structure.

So concept is:

1. Work internally with 64 bit integers.

2. Use bitmode to switch to something else on reading and writing.

Might give the programmers of free pascal maybe an idea for the future for
some kind of language extension lol.

I am not counting on it... but who knows :)

I shall give a little example to give a better idea:

Tstructure1 = record
    blablabla
end;

Tstructure2 =
    bla
    blablabla
    bla
end;

TstructureType = ( Tstructure1, Tstructure2 )

var
    SomeVariable : TstructureType;
    SomeStructure : SomeStructure?;

begin
    somevariable := Tstructure1;

    select somestructure based on somevariable do
    begin
        blablabla := 464; // structure1.blablabla
    end;
end;

Bye,
  Skybuck.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Can you knock my socks off ? Can you mimic Skybuck's/Delphi's Major Breakthrough for code path and memory structure selection ?

Matt Emson
In reply to this post by Peter Vreman
Peter Vreman wrote:

>> None the less very interesting example.
>>
>> Problem is ofcourse FPC does not support the new Delphi 2007 features.
>>
>> And the big question is how would you port this code to FPC ?
>
> Please don't make _your_ problem our problem!!!
>
> You knew beforehand that FPC doesn't support these features. If you
> want to be compiler independent you have to keep to the smallest
> feature set.
>
> Writing multiple mails with complains will not help to get features in
> the compiler.

I don't think this guy actually listens to anything anyone says to him.
He always seems, to me, to be speaking to an audience, rather than a
discussion list.

Adios Sybuck Flying, added you to my ignore list ;-)

M
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Can you knock my socks off ? Canyou mimic Skybuck's/Delphi'sMajor Breakthrough for code path and memory structure selection ?

Skybuck Flying
Oh by I do listen.

This mailing list has been most usefull to solving some of the problems :)

Thanks people ! =D

Bye,
  Skybuck ;)
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Can you knock my socks off ? Can you mimic Skybuck's/Delphi's Major Breakthrough for code path and memory structure selection ?

Luiz Americo Pereira Camara-2
In reply to this post by Matt Emson
Matt Emson wrote:
> I don't think this guy actually listens to anything anyone says to
> him. He always seems, to me, to be speaking to an audience, rather
> than a discussion list.
>
> Adios Sybuck Flying, added you to my ignore list ;-)
>
+1

Luiz
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Can you knock my socks off ? Can you mimic Skybuck's/Delphi's Major Breakthrough for code path and memory structure selection ?

Milan Marusinec
Luiz Americo Pereira Camara wrote:
> Matt Emson wrote:
>> I don't think this guy actually listens to anything anyone says to
>> him. He always seems, to me, to be speaking to an audience, rather
>> than a discussion list.
>>
>> Adios Sybuck Flying, added you to my ignore list ;-)
>>
> +1
Googling for term "Skyfuck Flying" gives an enormous number of postings to
various mailing lists all over the world. I think this guy is trying to
create
a Guiness record in posting per year or something silly like that ...

Milano

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: Can you knock my socks off ? Can you mimic Skybuck's/Delphi's Major Breakthrough for code path and memory structure selection ?

Henry Vermaak
On 12/02/2008, Milan Marusinec <[hidden email]> wrote:
> Googling for term "Skyfuck Flying" gives an enormous number of postings to
> various mailing lists all over the world. I think this guy is trying to
> create
> a Guiness record in posting per year or something silly like that ...

just google "skybuck flying plonk".  i'd think the guinness record
would be for _trolling_, as opposed to posting.

henry
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal