Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #54817 > unrolled thread

A data type for a wider integer than the compiler supports

Back to article view | Back to comp.lang.c

Contents

  A data type for a wider integer than the compiler supports "James Harris" <james.harris.1@gmail.com> - 2014-12-17 10:04 +0000
    Re: A data type for a wider integer than the compiler supports Robert Wessel <robertwessel2@yahoo.com> - 2014-12-18 02:48 -0600
      Re: A data type for a wider integer than the compiler supports "James Harris" <james.harris.1@gmail.com> - 2014-12-18 14:30 +0000
        Re: A data type for a wider integer than the compiler supports bert <bert.hutchings@btinternet.com> - 2014-12-18 11:49 -0800
        Re: A data type for a wider integer than the compiler supports Robert Wessel <robertwessel2@yahoo.com> - 2014-12-18 14:27 -0600
          Re: A data type for a wider integer than the compiler supports "James Harris" <james.harris.1@gmail.com> - 2015-01-27 16:30 +0000
            Re: A data type for a wider integer than the compiler supports Thomas Richter <thor@math.tu-berlin.de> - 2015-01-29 15:53 +0100
              Re: A data type for a wider integer than the compiler supports Bartc <bc@freeuk.com> - 2015-01-29 17:33 +0000
                Re: A data type for a wider integer than the compiler supports Richard Heathfield <invalid@see.sig.invalid> - 2015-01-29 17:52 +0000
                  Re: A data type for a wider integer than the compiler supports Bartc <bc@freeuk.com> - 2015-01-29 18:24 +0000
                    Re: A data type for a wider integer than the compiler supports Richard Heathfield <invalid@see.sig.invalid> - 2015-01-29 18:42 +0000
              Re: A data type for a wider integer than the compiler supports "James Harris" <james.harris.1@gmail.com> - 2015-01-30 09:56 +0000
                Re: A data type for a wider integer than the compiler supports Richard Heathfield <invalid@see.sig.invalid> - 2015-01-30 10:13 +0000
                  Re: A data type for a wider integer than the compiler supports "James Harris" <james.harris.1@gmail.com> - 2015-01-30 13:21 +0000
                    Re: A data type for a wider integer than the compiler supports Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-30 14:16 +0000
                    Re: A data type for a wider integer than the compiler supports Thomas Richter <thor@math.tu-berlin.de> - 2015-02-01 08:54 +0100
              Re: A data type for a wider integer than the compiler supports Richard Heathfield <invalid@see.sig.invalid> - 2015-01-30 10:17 +0000
    Re: A data type for a wider integer than the compiler supports BartC <bc@freeuk.com> - 2014-12-18 10:13 +0000
      Re: A data type for a wider integer than the compiler supports BartC <bc@freeuk.com> - 2014-12-18 12:34 +0000
      Re: A data type for a wider integer than the compiler supports "James Harris" <james.harris.1@gmail.com> - 2014-12-18 15:06 +0000
    Re: A data type for a wider integer than the compiler supports Nobody <nobody@nowhere.invalid> - 2014-12-18 10:27 +0000
      Re: A data type for a wider integer than the compiler supports Robert Wessel <robertwessel2@yahoo.com> - 2014-12-18 04:44 -0600
        Re: A data type for a wider integer than the compiler supports "James Harris" <james.harris.1@gmail.com> - 2014-12-18 15:21 +0000
          Re: A data type for a wider integer than the compiler supports Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-18 20:33 +0000
            Re: A data type for a wider integer than the compiler supports "James Harris" <james.harris.1@gmail.com> - 2014-12-22 16:25 +0000
              Re: A data type for a wider integer than the compiler supports Robert Wessel <robertwessel2@yahoo.com> - 2014-12-22 14:38 -0600
                Re: A data type for a wider integer than the compiler supports Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-22 21:14 +0000
                Re: A data type for a wider integer than the compiler supports "James Harris" <james.harris.1@gmail.com> - 2014-12-23 02:42 +0000
                  Re: A data type for a wider integer than the compiler supports Robert Wessel <robertwessel2@yahoo.com> - 2014-12-22 22:52 -0600
                    Re: A data type for a wider integer than the compiler supports "James Harris" <james.harris.1@gmail.com> - 2014-12-23 11:00 +0000
                      Re: A data type for a wider integer than the compiler supports Les Cargill <lcargill99@comcast.com> - 2014-12-23 14:46 -0600
                      Re: A data type for a wider integer than the compiler supports Robert Wessel <robertwessel2@yahoo.com> - 2014-12-24 05:21 -0600
                  Re: A data type for a wider integer than the compiler supports David Brown <david.brown@hesbynett.no> - 2014-12-23 08:13 +0100
              Re: A data type for a wider integer than the compiler supports Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-22 20:02 +0000
                Re: A data type for a wider integer than the compiler supports "James Harris" <james.harris.1@gmail.com> - 2014-12-23 02:33 +0000
                  Re: A data type for a wider integer than the compiler supports Robert Wessel <robertwessel2@yahoo.com> - 2014-12-22 23:05 -0600
                    Re: A data type for a wider integer than the compiler supports Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-23 09:57 +0000
                      Re: A data type for a wider integer than the compiler supports "James Harris" <james.harris.1@gmail.com> - 2014-12-23 10:49 +0000
              Re: A data type for a wider integer than the compiler supports Kaz Kylheku <kaz@kylheku.com> - 2014-12-22 21:18 +0000
      Re: A data type for a wider integer than the compiler supports Keith Thompson <kst-u@mib.org> - 2014-12-18 10:12 -0800
    Re: A data type for a wider integer than the compiler supports Vincenzo Mercuri <nomail@yahoo.it> - 2014-12-18 18:52 +0100
      Re: A data type for a wider integer than the compiler supports "James Harris" <james.harris.1@gmail.com> - 2014-12-18 18:17 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#54922

On Wed, 17 Dec 2014 10:04:25 +0000, James Harris wrote:

> But what options are there for defining ui64 when using the 16-bit compiler 
> (when 32-bit ints are the widest it supports, and when it cannot pass 
> structs to and from functions)?

In C, function parameters and return values can be structs.

If the compiler doesn't support that, it isn't a C compiler (and whatever
language it's a compiler for is off-topic here).

[toc] | [prev] | [next] | [standalone]

#54924

On Thu, 18 Dec 2014 10:27:22 +0000, Nobody <nobody@nowhere.invalid>
wrote:

>On Wed, 17 Dec 2014 10:04:25 +0000, James Harris wrote:
>
>> But what options are there for defining ui64 when using the 16-bit compiler 
>> (when 32-bit ints are the widest it supports, and when it cannot pass 
>> structs to and from functions)?
>
>In C, function parameters and return values can be structs.
>
>If the compiler doesn't support that, it isn't a C compiler (and whatever
>language it's a compiler for is off-topic here).


I completely missed that.

In any event, has there ever been any version of bcc (and I'm assuming
we're talking about the Borland compiler) that didn't support passing
and returning structs to and from functions?  Even the predecessor to
bcc, Turbo-C, was originally released in 1987.  While that's
pre-standard, the ability to do that had long been common in C
compilers.  Certainly anything branded as bcc post-dates the standard.

[toc] | [prev] | [next] | [standalone]

#54956

"Robert Wessel" <robertwessel2@yahoo.com> wrote in message 
news:iib59al1i0jtqb8behdmqq8aamr1a4k46o@4ax.com...
> On Thu, 18 Dec 2014 10:27:22 +0000, Nobody <nobody@nowhere.invalid>
> wrote:
>
>>On Wed, 17 Dec 2014 10:04:25 +0000, James Harris wrote:
>>
>>> But what options are there for defining ui64 when using the 16-bit 
>>> compiler
>>> (when 32-bit ints are the widest it supports, and when it cannot pass
>>> structs to and from functions)?
>>
>>In C, function parameters and return values can be structs.
>>
>>If the compiler doesn't support that, it isn't a C compiler (and whatever
>>language it's a compiler for is off-topic here).
>
>
> I completely missed that.
>
> In any event, has there ever been any version of bcc (and I'm assuming
> we're talking about the Borland compiler) that didn't support passing
> and returning structs to and from functions?  Even the predecessor to
> bcc, Turbo-C, was originally released in 1987.  While that's
> pre-standard, the ability to do that had long been common in C
> compilers.  Certainly anything branded as bcc post-dates the standard.

No, in this case bcc is the pre-ANSI

  http://linux.die.net/man/1/bcc

Even though it does not copy structs (unfortunately) it seems to be the best 
compiler available for producing 16-bit x86 code under Unix. Alexei Frounze 
is actively developing Smaller C which may, one day, do more but even it 
does not copy structs yet.

James

[toc] | [prev] | [next] | [standalone]

#54994

"James Harris" <james.harris.1@gmail.com> writes:
<snip>
> No, in this case bcc is the pre-ANSI
>
>   http://linux.die.net/man/1/bcc
>
> Even though it does not copy structs (unfortunately) it seems to be the best 
> compiler available for producing 16-bit x86 code under Unix.

What does not copy structs mean?  I just gave bcc a spin and it accepts
a function with a struct parameter.  The generated code looks sane too
(though I don't really know the instruction set).  I can't actually run
the code because the emulator is unavailable on my system, so maybe it's
not really doing what I think.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#55290

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:87zjakwve1.fsf@bsb.me.uk...
> "James Harris" <james.harris.1@gmail.com> writes:
> <snip>
>> No, in this case bcc is the pre-ANSI
>>
>>   http://linux.die.net/man/1/bcc
>>
>> Even though it does not copy structs (unfortunately) it seems to be the 
>> best
>> compiler available for producing 16-bit x86 code under Unix.
>
> What does not copy structs mean?

I meant struct pass-by-value and assignment. I thought I read that bcc will 
not support that - but I cannot find the comment just now.

> I just gave bcc a spin and it accepts
> a function with a struct parameter.  The generated code looks sane too
> (though I don't really know the instruction set).

If it helps, bcc is a pre-ANSI compiler. AIUI it passes ansi C through 
unprotoize.

  http://linux.die.net/man/1/unprotoize

Is pre-ANSI C the same as K&R C? And did it support pass-by-value for 
structures?

>  I can't actually run
> the code because the emulator is unavailable on my system, so maybe it's
> not really doing what I think.

That's odd. On my system elksemu seems to have come in the bcc package. If 
that and the bin86 package are installed then the following script will 
build and run hello.c.

$ cat hello86-make.sh
#!/bin/sh
# Make an 8086 executable and run it

prog=hello

bcc -ansi -S -o ${prog}.s ${prog}.c
as86 -0 -u -o ${prog}.o ${prog}.s
ld86 -0 -i -L/usr/lib/bcc -C0 -lc -o ${prog} ${prog}.o
elksemu ${prog}
$

James

[toc] | [prev] | [next] | [standalone]

#55308

On Mon, 22 Dec 2014 16:25:29 -0000, "James Harris"
<james.harris.1@gmail.com> wrote:

>"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
>news:87zjakwve1.fsf@bsb.me.uk...
>> "James Harris" <james.harris.1@gmail.com> writes:
>> <snip>
>>> No, in this case bcc is the pre-ANSI
>>>
>>>   http://linux.die.net/man/1/bcc
>>>
>>> Even though it does not copy structs (unfortunately) it seems to be the 
>>> best
>>> compiler available for producing 16-bit x86 code under Unix.
>>
>> What does not copy structs mean?
>
>I meant struct pass-by-value and assignment. I thought I read that bcc will 
>not support that - but I cannot find the comment just now.
>
>> I just gave bcc a spin and it accepts
>> a function with a struct parameter.  The generated code looks sane too
>> (though I don't really know the instruction set).
>
>If it helps, bcc is a pre-ANSI compiler. AIUI it passes ansi C through 
>unprotoize.
>
>  http://linux.die.net/man/1/unprotoize
>
>Is pre-ANSI C the same as K&R C? And did it support pass-by-value for 
>structures?


Sort-of.  While K&R was the defacto pre-ANSI C standard, there were
numerous extensions, and many deviations.  Being able to pass
structure by value was a fairly common extension.  Taking a quick look
at the source it looks like there's some accommodation in bcc for
structures in function calls, but it's not really clear what it's
doing.

Surely there's a better supported compiler available for whatever
platform you're targeting?

[toc] | [prev] | [next] | [standalone]

#55311

Robert Wessel <robertwessel2@yahoo.com> writes:

> On Mon, 22 Dec 2014 16:25:29 -0000, "James Harris"
<snip>
>>Is pre-ANSI C the same as K&R C? And did it support pass-by-value for 
>>structures?
>
>
> Sort-of.  While K&R was the defacto pre-ANSI C standard, there were
> numerous extensions, and many deviations.  Being able to pass
> structure by value was a fairly common extension.

I'd say it's in a different category than a common extension.  After
explaining that you can't pass or assign structures, the original K&R
says "these restrictions will be removed in a future version".

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#55328

"Robert Wessel" <robertwessel2@yahoo.com> wrote in message 
news:1bug9apk069qc21im6gcej6gl3b0ijnsr4@4ax.com...
> On Mon, 22 Dec 2014 16:25:29 -0000, "James Harris"
> <james.harris.1@gmail.com> wrote:

...

>>Is pre-ANSI C the same as K&R C? And did it support pass-by-value for
>>structures?
>
>
> Sort-of.  While K&R was the defacto pre-ANSI C standard, there were
> numerous extensions, and many deviations.  Being able to pass
> structure by value was a fairly common extension.  Taking a quick look
> at the source it looks like there's some accommodation in bcc for
> structures in function calls, but it's not really clear what it's
> doing.
>
> Surely there's a better supported compiler available for whatever
> platform you're targeting?

I'd welcome being pointed to a better compiler if there is one but I have 
asked here before. Requirements are basically to produce x86 real mode (i.e. 
16-bit) output and run on Linux. Unfortunately gcc will produce 32-bit and 
64-bit but not 16-bit. Most other 8086-producing compilers seem to run under 
DOS or Windows. Open Watcom C is supposed to have a Unix port but I could 
not get it to work. So I've been using bcc.

James

[toc] | [prev] | [next] | [standalone]

#55330

On Tue, 23 Dec 2014 02:42:34 -0000, "James Harris"
<james.harris.1@gmail.com> wrote:

>"Robert Wessel" <robertwessel2@yahoo.com> wrote in message 
>news:1bug9apk069qc21im6gcej6gl3b0ijnsr4@4ax.com...
>> On Mon, 22 Dec 2014 16:25:29 -0000, "James Harris"
>> <james.harris.1@gmail.com> wrote:
>
>...
>
>>>Is pre-ANSI C the same as K&R C? And did it support pass-by-value for
>>>structures?
>>
>>
>> Sort-of.  While K&R was the defacto pre-ANSI C standard, there were
>> numerous extensions, and many deviations.  Being able to pass
>> structure by value was a fairly common extension.  Taking a quick look
>> at the source it looks like there's some accommodation in bcc for
>> structures in function calls, but it's not really clear what it's
>> doing.
>>
>> Surely there's a better supported compiler available for whatever
>> platform you're targeting?
>
>I'd welcome being pointed to a better compiler if there is one but I have 
>asked here before. Requirements are basically to produce x86 real mode (i.e. 
>16-bit) output and run on Linux. Unfortunately gcc will produce 32-bit and 
>64-bit but not 16-bit. Most other 8086-producing compilers seem to run under 
>DOS or Windows. Open Watcom C is supposed to have a Unix port but I could 
>not get it to work. So I've been using bcc.


Most of the DOS ones should run under DOSBox.  Heck you could use
Borland's 16 bit compiler, and still be using bcc!  ;-)

http://www.dosbox.com/wiki/Software:Borland_Turbo_C

DOSEMU also exists, but I've never used it.

[toc] | [prev] | [next] | [standalone]

#55351

"Robert Wessel" <robertwessel2@yahoo.com> wrote in message 
news:5psh9alh6vfhuqib2n42hi157hd985ndom@4ax.com...
> On Tue, 23 Dec 2014 02:42:34 -0000, "James Harris"
> <james.harris.1@gmail.com> wrote:

...

>>I'd welcome being pointed to a better compiler if there is one but I have
>>asked here before. Requirements are basically to produce x86 real mode 
>>(i.e.
>>16-bit) output and run on Linux. Unfortunately gcc will produce 32-bit and
>>64-bit but not 16-bit. Most other 8086-producing compilers seem to run 
>>under
>>DOS or Windows. Open Watcom C is supposed to have a Unix port but I could
>>not get it to work. So I've been using bcc.
>
>
> Most of the DOS ones should run under DOSBox.  Heck you could use
> Borland's 16 bit compiler, and still be using bcc!  ;-)
>
> http://www.dosbox.com/wiki/Software:Borland_Turbo_C
>
> DOSEMU also exists, but I've never used it.

That's an intriguing idea. I would need to control the compiler from the 
Linux command line and have it access Linux files but DOSEMU seems as though 
it *might* allow that:

  http://www.dosemu.org/docs/README/1.4/x724.html

Any recommendations for a DOS-based ANSI C compiler? (I'm not sure if you 
were recommending Borland or just mentioning it.) The compiler would need to 
be controllable from the command line as there will be no GUI.

Incidentally, I found another C compiler called bcc so there are at least 
three of them with the same name!

  http://www.gaisler.com/index.php/products?option=com_content&task=view&id=147

James

[toc] | [prev] | [next] | [standalone]

#55372

James Harris wrote:
> "Robert Wessel" <robertwessel2@yahoo.com> wrote in message
> news:5psh9alh6vfhuqib2n42hi157hd985ndom@4ax.com...
>> On Tue, 23 Dec 2014 02:42:34 -0000, "James Harris"
>> <james.harris.1@gmail.com> wrote:
>
> ...
>
>>> I'd welcome being pointed to a better compiler if there is one but I have
>>> asked here before. Requirements are basically to produce x86 real mode
>>> (i.e.
>>> 16-bit) output and run on Linux. Unfortunately gcc will produce 32-bit and
>>> 64-bit but not 16-bit. Most other 8086-producing compilers seem to run
>>> under
>>> DOS or Windows. Open Watcom C is supposed to have a Unix port but I could
>>> not get it to work. So I've been using bcc.
>>
>>
>> Most of the DOS ones should run under DOSBox.  Heck you could use
>> Borland's 16 bit compiler, and still be using bcc!  ;-)
>>
>> http://www.dosbox.com/wiki/Software:Borland_Turbo_C
>>
>> DOSEMU also exists, but I've never used it.
>
> That's an intriguing idea. I would need to control the compiler from the
> Linux command line and have it access Linux files but DOSEMU seems as though
> it *might* allow that:
>
>    http://www.dosemu.org/docs/README/1.4/x724.html
>

Bizarre :)

> Any recommendations for a DOS-based ANSI C compiler? (I'm not sure if you
> were recommending Borland or just mentioning it.)

As I recall, Borland is a subset of ANSI. It may well be full ANSI and
I just don't remember.

> The compiler would need to
> be controllable from the command line as there will be no GUI.
>
> Incidentally, I found another C compiler called bcc so there are at least
> three of them with the same name!
>
>    http://www.gaisler.com/index.php/products?option=com_content&task=view&id=147
>
> James
>
>

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#55381

On Tue, 23 Dec 2014 11:00:35 -0000, "James Harris"
<james.harris.1@gmail.com> wrote:

>"Robert Wessel" <robertwessel2@yahoo.com> wrote in message 
>news:5psh9alh6vfhuqib2n42hi157hd985ndom@4ax.com...
>> On Tue, 23 Dec 2014 02:42:34 -0000, "James Harris"
>> <james.harris.1@gmail.com> wrote:
>
>...
>
>>>I'd welcome being pointed to a better compiler if there is one but I have
>>>asked here before. Requirements are basically to produce x86 real mode 
>>>(i.e.
>>>16-bit) output and run on Linux. Unfortunately gcc will produce 32-bit and
>>>64-bit but not 16-bit. Most other 8086-producing compilers seem to run 
>>>under
>>>DOS or Windows. Open Watcom C is supposed to have a Unix port but I could
>>>not get it to work. So I've been using bcc.
>>
>>
>> Most of the DOS ones should run under DOSBox.  Heck you could use
>> Borland's 16 bit compiler, and still be using bcc!  ;-)
>>
>> http://www.dosbox.com/wiki/Software:Borland_Turbo_C
>>
>> DOSEMU also exists, but I've never used it.
>
>That's an intriguing idea. I would need to control the compiler from the 
>Linux command line and have it access Linux files but DOSEMU seems as though 
>it *might* allow that:
>
>  http://www.dosemu.org/docs/README/1.4/x724.html


DOSBox does something similar.


>Any recommendations for a DOS-based ANSI C compiler? (I'm not sure if you 
>were recommending Borland or just mentioning it.) The compiler would need to 
>be controllable from the command line as there will be no GUI.


I think the more recent versions of Borland's 16-bit product were
fully C89, and many people think well of it.  Personally I mainly used
MS's product, and the last release they had of a 16 bit compiler (MSVC
1.5), seems to run just fine under DOSBox (I just tried your sample
program from a few posts back).  Unfortunately you're going to
probably have issues getting a licensed copy of that.

[toc] | [prev] | [next] | [standalone]

#55333

On 23/12/14 03:42, James Harris wrote:
> "Robert Wessel" <robertwessel2@yahoo.com> wrote in message 
> news:1bug9apk069qc21im6gcej6gl3b0ijnsr4@4ax.com...
>> On Mon, 22 Dec 2014 16:25:29 -0000, "James Harris"
>> <james.harris.1@gmail.com> wrote:
> 
> ...
> 
>>> Is pre-ANSI C the same as K&R C? And did it support pass-by-value for
>>> structures?
>>
>>
>> Sort-of.  While K&R was the defacto pre-ANSI C standard, there were
>> numerous extensions, and many deviations.  Being able to pass
>> structure by value was a fairly common extension.  Taking a quick look
>> at the source it looks like there's some accommodation in bcc for
>> structures in function calls, but it's not really clear what it's
>> doing.
>>
>> Surely there's a better supported compiler available for whatever
>> platform you're targeting?
> 
> I'd welcome being pointed to a better compiler if there is one but I have 
> asked here before. Requirements are basically to produce x86 real mode (i.e. 
> 16-bit) output and run on Linux. Unfortunately gcc will produce 32-bit and 
> 64-bit but not 16-bit. Most other 8086-producing compilers seem to run under 
> DOS or Windows. Open Watcom C is supposed to have a Unix port but I could 
> not get it to work. So I've been using bcc.
> 
> James
> 

You've probably already looked, but in case you haven't - the FreeDOS
site might have ideas on compilers to suit you (for compiling FreeDOS
itself, rather than for running under FreeDOS - unless you go for a
DOSBox setup).

[toc] | [prev] | [next] | [standalone]

#55310

"James Harris" <james.harris.1@gmail.com> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
> news:87zjakwve1.fsf@bsb.me.uk...
>> "James Harris" <james.harris.1@gmail.com> writes:
>> <snip>
>>> No, in this case bcc is the pre-ANSI
>>>
>>>   http://linux.die.net/man/1/bcc
>>>
>>> Even though it does not copy structs (unfortunately) it seems to be the 
>>> best
>>> compiler available for producing 16-bit x86 code under Unix.
>>
>> What does not copy structs mean?
>
> I meant struct pass-by-value and assignment. I thought I read that bcc will 
> not support that - but I cannot find the comment just now.
>
>> I just gave bcc a spin and it accepts
>> a function with a struct parameter.  The generated code looks sane too
>> (though I don't really know the instruction set).
>
> If it helps, bcc is a pre-ANSI compiler. AIUI it passes ansi C through 
> unprotoize.

Yes, I know, thanks.

>   http://linux.die.net/man/1/unprotoize
>
> Is pre-ANSI C the same as K&R C?

No.  Pre standardisation there were lots of versions of C, mostly with
small variations in the language and more significant variations in the
library they came with.

> And did it support pass-by-value for 
> structures?

The language in K&R does not but it says that it may come along soon and
indeed it did.  Every C compiler I ever used, after about 1979,
supported struct assignment, passing and return (though I am sure some
came late to the party -- I was probably just fortunate).

>>  I can't actually run
>> the code because the emulator is unavailable on my system, so maybe it's
>> not really doing what I think.
>
> That's odd. On my system elksemu seems to have come in the bcc
> package.

It doesn't on my system despite the package description saying that it
does.  I suspect it's down to elksemu not working with newer 64-bit
kernels, but I did not investigate very much.

But you can check.  Does bcc support struct passing etc?  As I said, the
assembler code looks sane and there should really be a warning if the
compiler does not support it.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#55327

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:m7a12i$pgd$1@dont-email.me...

...

> But you can check.  Does bcc support struct passing etc?  As I said, the
> assembler code looks sane and there should really be a warning if the
> compiler does not support it.

In a couple of simple tests I found that structs were copied and returned 
successfully but not passed. For example:

/*
 * Test struct passing
 */

#include <stdio.h>

struct pair {
  int a;
  int b;
};

struct pair printer(struct pair);

int main(void) {
  struct pair original, copy;

  original.a = 5;
  original.b = 7;
  copy = printer(original);
  printf("returned pair = %i,%i\n", copy.a, copy.b);
  return 0;
}

struct pair printer(struct pair x) {

  printf("pair = %i,%i\n", x.a, x.b);
  return x;
}

The output is
pair = 5903,22
returned pair = 5903,22

Is the code valid? If so, what else could be the problem? Looking at the 
generated code it seems to make an effort to pass the struct by calling 
_memcpy but the parameter setup may be wrong.

James

[toc] | [prev] | [next] | [standalone]

#55331

On Tue, 23 Dec 2014 02:33:35 -0000, "James Harris"
<james.harris.1@gmail.com> wrote:

>"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
>news:m7a12i$pgd$1@dont-email.me...
>
>...
>
>> But you can check.  Does bcc support struct passing etc?  As I said, the
>> assembler code looks sane and there should really be a warning if the
>> compiler does not support it.
>
>In a couple of simple tests I found that structs were copied and returned 
>successfully but not passed. For example:
>
>/*
> * Test struct passing
> */
>
>#include <stdio.h>
>
>struct pair {
>  int a;
>  int b;
>};
>
>struct pair printer(struct pair);
>
>int main(void) {
>  struct pair original, copy;
>
>  original.a = 5;
>  original.b = 7;
>  copy = printer(original);
>  printf("returned pair = %i,%i\n", copy.a, copy.b);
>  return 0;
>}
>
>struct pair printer(struct pair x) {
>
>  printf("pair = %i,%i\n", x.a, x.b);
>  return x;
>}
>
>The output is
>pair = 5903,22
>returned pair = 5903,22
>
>Is the code valid? If so, what else could be the problem? Looking at the 
>generated code it seems to make an effort to pass the struct by calling 
>_memcpy but the parameter setup may be wrong.


It has been *sooo* long since I've done a K&R prototype...

But doesn't the second routine have to be:


struct pair printer(x)
 struct pair x;
 {
  printf("pair = %i,%i\n", x.a, x.b);
  return x;
}

[toc] | [prev] | [next] | [standalone]

#55344

Robert Wessel <robertwessel2@yahoo.com> writes:

> On Tue, 23 Dec 2014 02:33:35 -0000, "James Harris"
> <james.harris.1@gmail.com> wrote:
>
>>"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
>>news:m7a12i$pgd$1@dont-email.me...
<snip>
>>> But you can check.  Does bcc support struct passing etc?
<snip>
>>In a couple of simple tests I found that structs were copied and returned 
>>successfully but not passed. For example:
<snip>
>>struct pair printer(struct pair x) {
>>
>>  printf("pair = %i,%i\n", x.a, x.b);
>>  return x;
>>}
<snip>
> It has been *sooo* long since I've done a K&R prototype...
>
> But doesn't the second routine have to be:
>
>
> struct pair printer(x)
>  struct pair x;
>  {
>   printf("pair = %i,%i\n", x.a, x.b);
>   return x;
> }

I was going to suggest just this.  bcc handles ANSI function prototype
with a pre-processing pass, so I'd certainly want to eliminate an error
in that part of the compilation by reverting to K&R C.  Mind you, that
won't help James if he needs the -ansi flag for other reasons.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#55350

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:873886lmcf.fsf@bsb.me.uk...
> Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> On Tue, 23 Dec 2014 02:33:35 -0000, "James Harris"
>> <james.harris.1@gmail.com> wrote:
>>
>>>"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>>news:m7a12i$pgd$1@dont-email.me...
> <snip>
>>>> But you can check.  Does bcc support struct passing etc?
> <snip>
>>>In a couple of simple tests I found that structs were copied and returned
>>>successfully but not passed. For example:
> <snip>
>>>struct pair printer(struct pair x) {
>>>
>>>  printf("pair = %i,%i\n", x.a, x.b);
>>>  return x;
>>>}
> <snip>
>> It has been *sooo* long since I've done a K&R prototype...
>>
>> But doesn't the second routine have to be:
>>
>>
>> struct pair printer(x)
>>  struct pair x;
>>  {
>>   printf("pair = %i,%i\n", x.a, x.b);
>>   return x;
>> }
>
> I was going to suggest just this.  bcc handles ANSI function prototype
> with a pre-processing pass, so I'd certainly want to eliminate an error
> in that part of the compilation by reverting to K&R C.  Mind you, that
> won't help James if he needs the -ansi flag for other reasons.

Yes, gcc compiles the same source files so the compatibility is needed.

It should probably always be a last resort to blame the compiler but in this 
case it does look as though bcc may be at fault. Its struct passing assembly 
code seems to push the memcpy length twice, once instead of the dest 
pointer. I may make up a minimal example and see if there's somewhere I can 
file a bug report.

James

[toc] | [prev] | [next] | [standalone]

#55312

On 2014-12-22, James Harris <james.harris.1@gmail.com> wrote:
> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
> news:87zjakwve1.fsf@bsb.me.uk...
>> "James Harris" <james.harris.1@gmail.com> writes:
>> <snip>
>>> No, in this case bcc is the pre-ANSI
>>>
>>>   http://linux.die.net/man/1/bcc
>>>
>>> Even though it does not copy structs (unfortunately) it seems to be the 
>>> best
>>> compiler available for producing 16-bit x86 code under Unix.
> >
>> What does not copy structs mean?
>
> I meant struct pass-by-value and assignment. I thought I read that bcc will 
> not support that - but I cannot find the comment just now.
>
>> I just gave bcc a spin and it accepts
>> a function with a struct parameter.  The generated code looks sane too
>> (though I don't really know the instruction set).
>
> If it helps, bcc is a pre-ANSI compiler. AIUI it passes ansi C through 
> unprotoize.
>
>   http://linux.die.net/man/1/unprotoize
>
> Is pre-ANSI C the same as K&R C? And did it support pass-by-value for 
> structures?

There are two questions there: is there support? If so, what kind of support?

In the pre-ANSI era, even though some compilers "supported" passing and
returning strucures, some of those compilers did that via static
memory areas, rather than via automatic storage ("on the stack").

That could work well under many use cases, even recursion, though obviously
failing to be re-entrant for situations involving signal handlers, interrupts
and threads.

Quite possibly, the use of static areas could cause problems in situations
where a single expression is crammed with multiple calls to functions
that accept or return structs, if some of the areas overlap, and the
code is wrongly interleaved.

[toc] | [prev] | [next] | [standalone]

#54979

Nobody <nobody@nowhere.invalid> writes:
> On Wed, 17 Dec 2014 10:04:25 +0000, James Harris wrote:
>> But what options are there for defining ui64 when using the 16-bit compiler 
>> (when 32-bit ints are the widest it supports, and when it cannot pass 
>> structs to and from functions)?
>
> In C, function parameters and return values can be structs.
>
> If the compiler doesn't support that, it isn't a C compiler (and whatever
> language it's a compiler for is off-topic here).

For that matter, if a compiler doesn't support type a long long type
that's at least 64 bits wide, it's also not a C compiler (at least not
one conforming to the C99 or later standard).

Still, implementing 64-bit arithmetic using a language that doesn't
support native integers wider than 32 bits is interesting, and any
solutions are likely to scale to implementing 2*N-bit arithmetic using
only N-bit native integers.  (By "native", I mean supported by the
compiler; operations might still be implemented via function calls.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web