comp.lang.ada
 help / color / mirror / Atom feed
* General integer-types.
@ 2013-04-07  1:45 Shark8
  2013-04-07  8:45 ` J-P. Rosen
  0 siblings, 1 reply; 3+ messages in thread
From: Shark8 @ 2013-04-07  1:45 UTC (permalink / raw)


I'm toying with the idea of making a SWF-player (I found the documentation for the format online) and was wondering about the integers. Sure I could write out all of them (8-bit, 16-bit, 32-bit)x(signed, unsigned) + 64-bit unsigned  = 7-types -- not too bad, but this is a lot of repetition so could I make a generic to qualify?

    Generic
	Size : Positive;
    Package SWF_Integer is
	Exp : Constant Positive := Size-1;
	
	-- For some reason adding the "New Long_Long_Integer" allows
	-- this to compile... but it might ignore the Size aspect.
	Type Signed is New Long_Long_Integer Range -2**Exp..2**Exp-1
	with Size => Size;
        
        -- This doesn't work at all; Size is not static.	
	Type Unsigned is Mod 0..2**Size
	with Size => Size;
	
    End SWF_Integer;

The specs are as follows:
> Integer types and byte order
> The SWF file format uses 8-bit, 16-bit, 32-bit, 64-bit, signed, 
> and unsigned integer types. All integer values are stored in the
> SWF file by using little-endian byte order: the least
> significant byte is stored first, and the most significant byte
> is stored last, in the same way as the Intel x86 architecture.
> The bit order within bytes in the SWF file format is big-endian:
> the most significant bit is stored first, and the least
> significant bit is stored last.
> 
> All integer types must be byte-aligned. That is, the first bit
> of an integer value must be stored in the first bit of a byte in
> the SWF file.

Would the bit_order definition work on ensuring the correct representation? The documentation seems to indicate it is for the bit-numbering in record-representations. Further, would the alignment definition (alignment => 1? 8?) be appropriate?

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: General integer-types.
  2013-04-07  1:45 General integer-types Shark8
@ 2013-04-07  8:45 ` J-P. Rosen
  2013-04-07 14:29   ` Shark8
  0 siblings, 1 reply; 3+ messages in thread
From: J-P. Rosen @ 2013-04-07  8:45 UTC (permalink / raw)


Le 07/04/2013 03:45, Shark8 a écrit :
>     Generic
> 	Size : Positive;
>     Package SWF_Integer is
> 	Exp : Constant Positive := Size-1;
> 	
> 	-- For some reason adding the "New Long_Long_Integer" allows
> 	-- this to compile... but it might ignore the Size aspect.
> 	Type Signed is New Long_Long_Integer Range -2**Exp..2**Exp-1
> 	with Size => Size;
>         
>         -- This doesn't work at all; Size is not static.	
> 	Type Unsigned is Mod 0..2**Size
> 	with Size => Size;
> 	
>     End SWF_Integer;
> 
A type definition must be static, and a size aspect too. A generic
formal is never static, therefore you can't define a type from a generic
parameter. (but of course, a constraint needs not be static, this is why
it works as a derived type). But then, all instantiations will use the
same size as Long_Long_Integer, which is likely not what you want.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: General integer-types.
  2013-04-07  8:45 ` J-P. Rosen
@ 2013-04-07 14:29   ` Shark8
  0 siblings, 0 replies; 3+ messages in thread
From: Shark8 @ 2013-04-07 14:29 UTC (permalink / raw)


On Sunday, April 7, 2013 2:45:59 AM UTC-6, J-P. Rosen wrote:
> 
> A type definition must be static, and a size aspect too. A generic
> formal is never static, therefore you can't define a type from a generic
> parameter. (but of course, a constraint needs not be static, this is why
> it works as a derived type). But then, all instantiations will use the
> same size as Long_Long_Integer, which is likely not what you want.
> 

Thanks for the clarification on the sizings (which was confusing).

I was just wondering, because it seemed like a rather common thing [*every* framework/system seems to define its own -- OpenGL, PS, SWE, etc] that it might be nice to be able to "throw the size at a generic" and get it.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-04-07 14:29 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-07  1:45 General integer-types Shark8
2013-04-07  8:45 ` J-P. Rosen
2013-04-07 14:29   ` Shark8

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox