Issues with LibMad

[Quackker12]

I have Turbo C 2.0, and in layer3.c, a variable called mantisa is
defined as:

unsigned long mantisa: 27;

The compiler says that the bit width is too large. How do I fix the
code so I can compile it?

regards,

(e-mail address removed)

 

[Vijay Kumar R Zanvar]

I have Turbo C 2.0, and in layer3.c, a variable called mantisa is
defined as:

unsigned long mantisa: 27;

Is mantisa a member of a structure? If not, then it's illegal to
define/declare bit-fields like this.

 

[Vijay Kumar R Zanvar]

Is mantisa a member of a structure? If not, then it's illegal to
define/declare bit-fields like this.

Moreover, the bit-field width is quite ok since, long are, at least, 32 bits wide.

 

[Darrell Grainger]

I have Turbo C 2.0, and in layer3.c, a variable called mantisa is
defined as:

unsigned long mantisa: 27;

The compiler says that the bit width is too large. How do I fix the
code so I can compile it?

Assuming it is just a matter of your compiler having a 16 bit long, you'll
have to check your compiler to see if there is an option to use 32 bit
long. Turbo C 2.0 is a *VERY* old compiler. It is entirely possible that
it does not support the ANSI C standard and has a 16 bit long (Windows 3.1
and older).

Even if you can get passed this problem you are probably going to find
other problems a new programmer shouldn't have to deal with. I would
recommend you search for "djgpp" or "cygwin". This will find an
implementation of the popular gcc compiler for MSDOS. It is free and much
more current.

 

[Darrell Grainger]

Moreover, the bit-field width is quite ok since, long are, at least, 32
bits wide.

You are assuming the compiler is ANSI C compliant. I started programming C
before the ANSI C standard (1989) and I remember using Turbo C 2.0. I
cannot remember for sure but I believe either Turbo C 1.5 or 2.0 predates
the ANSI C standard. It is entirely possible that the compiler uses a 16
bit long.

 

[Andrew]

You are assuming the compiler is ANSI C compliant. I started programming C
before the ANSI C standard (1989) and I remember using Turbo C 2.0. I
cannot remember for sure but I believe either Turbo C 1.5 or 2.0 predates
the ANSI C standard. It is entirely possible that the compiler uses a 16
bit long.

c:\tc>type width.c
#include <stdio.h>

int main(void)
{
printf("sizeof short: %d\n", sizeof(short));
printf("sizeof long : %d\n", sizeof(long));
printf("sizeof int : %d\n", sizeof(int));
return(1);
}

c:\tc>tcc -ml width.c
Turbo C Version 2.01 Copyright (c) 1987, 1988 Borland International
Turbo Link Version 2.0
[trimmed]

c:\tc>width
sizeof short: 2
sizeof long : 4
sizeof int : 2

The readme accompanying this version of Turbo C (most of the files are
dated May 11, 1989) makes note of a change in the ANSI draft about
labels, so it seems that Borland kept fairly well abreast of the
changes being made to the language.

As for the sizes of a long, the simple example above illustrates.
shorts and ints were 16-bits (the size of the x86's registers), while
longs were a full 32-bits. I believe that fact holds true for every
16-bit real-mode compiler ever produced for MS-DOS/16-bit Windows
systems.

Of course, I'm horribly off-topic for comp.lang.c.

 

[Eric Sosman]

I have Turbo C 2.0, and in layer3.c, a variable called mantisa is
defined as:

unsigned long mantisa: 27;

The compiler says that the bit width is too large. How do I fix the
code so I can compile it?

Others have mentioned that this syntax makes sense only
if `mantisa' is an element of a struct or union. There's no
hope of getting this to do anything sensible if `mantisa' is
a free-standing variable.

If `mantisa' *is* a struct or union element, the only
valid "base" types are the various flavors of `int' (and,
in the latest "C99" Standard, `_Bool'). A compiler is
allowed to accept `long' as the base type, but is not
required to do so.

Finally, the compiler is not required to accept a bit
count wider than the compiler's notion of `int'. Even if
the compiler supports a 32-bit `long' -- or a 64-bit `long'
or a 128-bit `long' -- it need not accept anything wider
than `int' as a bit field width.

Summary: There might not be anything you can do about
the problem, short of finding a different compiler.

 

[CBFalconer]

Assuming it is just a matter of your compiler having a 16 bit
long, you'll have to check your compiler to see if there is an
option to use 32 bit long. Turbo C 2.0 is a *VERY* old compiler.
It is entirely possible that it does not support the ANSI C
standard and has a 16 bit long (Windows 3.1 and older).

TC 2 supports the draft ANSI-89 standard. It is close to
compliant. The OPs problem has nothing to do with the size of
longs. I assume that declaration is part of a structure
definition (otherwise it is a syntax error) which the OP should
have shown in full. At any rate bit fields are sited in ints, not
longs. TC2 ints are 16 bits.

I suspect the OP is trying to play games with the floating
representation. That is unstandardized (in C), and would be
better (and non-portably, thus off topic) handled by examining the
byte patterns.

 

[Quackker12]

Others have mentioned that this syntax makes sense only
if `mantisa' is an element of a struct or union. There's no
hope of getting this to do anything sensible if `mantisa' is
a free-standing variable.

If `mantisa' *is* a struct or union element, the only
valid "base" types are the various flavors of `int' (and,
in the latest "C99" Standard, `_Bool'). A compiler is
allowed to accept `long' as the base type, but is not
required to do so.

Finally, the compiler is not required to accept a bit
count wider than the compiler's notion of `int'. Even if
the compiler supports a 32-bit `long' -- or a 64-bit `long'
or a 128-bit `long' -- it need not accept anything wider
than `int' as a bit field width.

Summary: There might not be anything you can do about
the problem, short of finding a different compiler.

Here is the structure that defines it:

static
struct fixedfloat {
unsigned long mantissa : 27;
unsigned short exponent : 5;
} const rq_table[8207] = {
# include "rq_table.dat"

Anyway, it looks like that I may need a new compiler. Can anyone
suggest a non 32-bit compiler that can handle this? (I am trying a
noble goal of writing a mp3 player for older machines...)

TIA

 

[Old Wolf]

If `mantisa' *is* a struct or union element, the only
valid "base" types are the various flavors of `int' (and,
in the latest "C99" Standard, `_Bool'). A compiler is
allowed to accept `long' as the base type, but is not
required to do so.

Finally, the compiler is not required to accept a bit
count wider than the compiler's notion of `int'. Even if
the compiler supports a 32-bit `long' -- or a 64-bit `long'
or a 128-bit `long' -- it need not accept anything wider
than `int' as a bit field width.

Summary: There might not be anything you can do about
the problem, short of finding a different compiler.

Here is the structure that defines it:

static
struct fixedfloat {
unsigned long mantissa : 27;
unsigned short exponent : 5;
} const rq_table[8207] = {
# include "rq_table.dat"

Anyway, it looks like that I may need a new compiler. Can anyone
suggest a non 32-bit compiler that can handle this? (I am trying a
noble goal of writing a mp3 player for older machines...)

TC 3 might be a bit better. Also you could investigate Watcom C
(I have a licenced copy of Watcom C for DOS. Recently they went
free and open-source, but I don't know if that applies to their
DOS versions retrospectively).

Of course, you could rewrite the code to not use those bitfields
(an excellent idea, since it's non-standard to use 'short' and
'long' as the types, as Eric pointed out).
Try something like:

assert(sizeof(long) * CHAR_BIT == 32);
#define MANTISSA(x) ( (unsigned long)(x) >> 5)
#define EXPONENT(x) ( (x) & 0x1FUL)
#define M_E(m,e) ((m##UL << 5) | e##UL)
const unsigned long rq_table[8207] = {
M_E(123,456),

etc.

 

[kal]

static
struct fixedfloat {
unsigned long mantissa : 27;
unsigned short exponent : 5;
} const rq_table[8207] = {
# include "rq_table.dat"

May be the following will work if the objective is to
get the float values.

static const float float_table[8207];

struct fixedfloat {
unsigned long m;
unsigned short e;
} const rq_table[8207] = {
# include "rq_table.dat"
}

unsigned long u;
for (int i=0; i<8207; i++)
{
u = ((unsigned long)rq_table.e << 27) |
((unsigned long)rq_table.m);
float_table = *((float *)(&u));
}

 

[Andrew]

TC 3 might be a bit better. Also you could investigate Watcom C
(I have a licenced copy of Watcom C for DOS. Recently they went
free and open-source, but I don't know if that applies to their
DOS versions retrospectively).

<OT>
OpenWatcom (http://www.openwatcom.org). Just about everything is
"open", although it's under their own license and not one of the more
popular "open source" licenses like the GPL. Basically, everything
that was actually produced by the Watcom developers is available.
Acquiring the SDK's for various platforms is up to the end user. OW
includes both the 16-bit and 32-bit C and C++ compilers, as well as
the Fortran compilers.

AFAIK, the freedoms of the current license does not apply to previous
versions of the software, as many of the components are licensed from
3rd parties and not really redistributable.
</OT>