Subj : Re: Inline Assembler bug with structs of certain size
To   : borland.public.cpp.borlandcpp
From : Ed Mulroy [TeamB]
Date : Wed Dec 01 2004 11:36 pm

Here is what you posted handled with BC++ 5.02.  Note
that -B is for compile via assembly and without -B it uses
the built in assembler (BASM) which won't align the code
on boundaries the same as is done when generating an
assembly language file and passing it to Tasm.  If I were
doing embedded work such as you are, I'd use -B and
add -TL to the command line so that I'd have a listing.

It's late now (11:30 PM) and I'm tired.  I'll look at it a bit more
tomorrow.

------------------
F:\Projects\lookat\q408
>bcc -1 -tDe -ml -B ques408.c
Borland C++ 5.2 Copyright (c) 1987, 1997 Borland International
Mar 19 1997 17:29:40
ques408.c:
Turbo Assembler  Version 4.1  Copyright (c) 1988, 1996 Borland International

Assembling file:   ques408.ASM
Error messages:    None
Warning messages:  None
Passes:            1
Remaining memory:  400k

Turbo Link  Version 7.1.32.2. Copyright (c) 1987, 1996 Borland International

F:\Projects\lookat\q408
>ques408
length of asm_test1 = 8
&TestStruct1 = 0b70, via asm = 1441
length of asm_test2 = 8
&TestStruct2 = 594a, via asm = 1441

F:\Projects\lookat\q408
>bcc -1 -tDe -ml ques408.c
Borland C++ 5.2 Copyright (c) 1987, 1997 Borland International
Mar 19 1997 17:29:40
ques408.c:
Turbo Link  Version 7.1.32.2. Copyright (c) 1987, 1996 Borland International

F:\Projects\lookat\q408
>ques408
length of asm_test1 = 8
&TestStruct1 = 0b70, via asm = 1441
length of asm_test2 = 5
&TestStruct2 = 594a, via asm = 1441

F:\Projects\lookat\q408
>
------------------

..  Ed

> Jeremy wrote in message
> news:41ae833d$1@newsgroups.borland.com...
>
> I found an interesting bug in the BC5.0B inline assembler
> today (after a couple of days tracking it down). I mention
> it here because it may still exist in newer versions.
>
> I have a large struct holding state information for a
> number of output objects. The other day I added a new
> member to the struct & all of a sudden my code (for an
> embedded 80188 CPU in a fire alarm panel) started
> mysteriously crashing soon after power-up. I eventually
> traced the problem to the fact that a couple of code
> fragments using inline assembler weren't working any more
> (were trashing system RAM instead of clearing elements in
> the struct).
>
> It turns out that my old structure (prior to the new
> element) was 19928 bytes long & the new one is 19932. I
> found that once you get over 19930 (it works OK again if
> you're above 20253!) the inline assembly statements using
> the structure address simply don't generate code! The
> following code illustrates the problem nicely:

>
> --------------------------------------------
> #include <stdio.h>
>
> static struct {
>  char Data[19930]; // OK
> // char Data[19931]; // Bad
> // char Data[20253]; // Bad
> // char Data[20254]; // OK
> } TestStruct1;
>
> static struct {
> // char Data[19930]; // OK
>  char Data[19931]; // Bad
> // char Data[20253]; // Bad
> // char Data[20254]; // OK
> } TestStruct2;
>
> unsigned asm_test1(void) {
>  asm {
>   mov  ax,OFFSET TestStruct1
>  }
>  return _AX;
> }
>
> unsigned asm_test2(void) {
>  asm {
>   mov  ax,OFFSET TestStruct2
>  }
>  return _AX;
> }
>
> void main(void) {
>
>  printf("length of asm_test1 = %u\n", (unsigned)asm_test2 -
> (unsigned)asm_test1);
>  _AX = 0xEEEE;
>  printf("&TestStruct1 = %04x, via asm = %04x\n", &TestStruct1,
asm_test1());
>
>  printf("length of asm_test2 = %u\n", (unsigned)main -
(unsigned)asm_test2);
>  _AX = 0xEEEE;
>  printf("&TestStruct2 = %04x, via asm = %04x\n", &TestStruct2,
asm_test2());
> }
> --------------------------------------------
>
> This code generates the following result:
>
> length of asm_test1 = 4
> &TestStruct1 = 0882, via asm = 0882
> length of asm_test2 = 1
> &TestStruct2 = 565c, via asm = eeee
>
> The generated code for the asm_test2() function ends up
> being a simple RET instruction! It seems to be pretty much
> independent of memory model & optimizations.
>
> I need the code to be in assembler for speed, & preferably
> near code (I use large memory model in my app), as the
> code is called frequently using a number of module-local
> variables. Any ideas for a workaround?

.