Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #106314 > unrolled thread
| Started by | Prashant Shah <pshah.mumbai@gmail.com> |
|---|---|
| First post | 2017-03-16 22:58 -0700 |
| Last post | 2017-03-19 13:26 +0100 |
| Articles | 20 on this page of 113 — 26 participants |
Back to article view | Back to comp.lang.c
Array allocated on stack or heap Prashant Shah <pshah.mumbai@gmail.com> - 2017-03-16 22:58 -0700
Re: Array allocated on stack or heap Barry Schwarz <schwarzb@dqel.com> - 2017-03-16 23:57 -0700
Re: Array allocated on stack or heap Mark Storkamp <mstorkamp@yahoo.com> - 2017-03-17 12:44 -0500
Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-17 11:26 -0700
Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 20:38 +0100
Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 16:08 -0400
Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:03 +0100
Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 20:54 -0400
Re: Array allocated on stack or heap John Bode <jfbode1029@gmail.com> - 2017-03-17 12:15 -0700
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-17 20:22 +0100
Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 20:45 +0100
Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-17 12:59 -0700
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-17 21:01 +0100
Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:12 +0100
Re: Array allocated on stack or heap jameskuyper@verizon.net - 2017-03-17 16:25 -0700
Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-17 17:08 -0700
Re: Array allocated on stack or heap Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-17 17:37 -0700
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 12:30 +0100
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 12:12 +0000
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 13:52 +0100
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 16:51 +0000
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 10:44 +0100
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-20 12:01 +0000
Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-20 06:02 -0700
Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-20 14:54 +0100
Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-20 07:28 -0700
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 16:43 +0100
Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-20 09:02 -0700
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 10:11 +0100
Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 02:48 -0700
Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-21 08:19 -0700
Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-21 08:17 -0700
Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-21 09:06 -0700
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 17:32 +0100
Re: Array allocated on stack or heap Les Cargill <lcargill99@comcast.com> - 2017-03-25 15:14 -0500
Re: Array allocated on stack or heap Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-25 16:05 -0700
Re: Array allocated on stack or heap Les Cargill <lcargill99@comcast.com> - 2017-03-25 23:53 -0500
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-26 12:30 +0100
Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-26 14:09 -0700
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-26 22:17 +0100
Re: Array allocated on stack or heap Robert Wessel <robertwessel2@yahoo.com> - 2017-03-26 21:52 -0500
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-27 13:06 +0100
Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-27 10:10 -0700
Re: Array allocated on stack or heap Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 15:56 -0500
Re: Array allocated on stack or heap bartc <bc@freeuk.com> - 2017-03-27 22:48 +0100
Re: Array allocated on stack or heap Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 19:58 -0500
Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-20 14:56 +0100
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 15:34 +0100
Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 09:28 -0700
Re: Array allocated on stack or heap bart4858@gmail.com - 2017-03-20 13:05 -0700
Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 13:53 -0700
Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 14:26 -0700
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-20 22:24 +0000
Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-20 15:44 -0700
Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 02:44 -0700
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 11:15 +0100
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-21 11:12 +0000
Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 04:23 -0700
Re: Array allocated on stack or heap scott@slp53.sl.home (Scott Lurndal) - 2017-03-21 13:13 +0000
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-21 13:38 +0000
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-21 15:33 +0100
Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 07:38 -0700
Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-21 07:35 -0700
Re: Array allocated on stack or heap scott@slp53.sl.home (Scott Lurndal) - 2017-03-21 15:09 +0000
Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 13:05 +0000
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 13:27 +0000
Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:26 +0100
Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 13:34 +0000
Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:35 +0100
Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 13:36 +0000
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 14:00 +0000
Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 19:00 +0000
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 19:24 +0000
Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-20 08:45 +1300
Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-19 14:32 -0700
Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-20 16:16 +1300
Re: Array allocated on stack or heap Gareth Owen <gwowen@gmail.com> - 2017-03-20 18:58 +0000
Re: Array allocated on stack or heap raltbos@xs4all.nl (Richard Bos) - 2017-03-24 09:17 +0000
Re: Array allocated on stack or heap Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-19 20:50 +0000
Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:10 +0100
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 13:38 +0000
Re: Array allocated on stack or heap GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-19 14:49 +0100
Re: Array allocated on stack or heap luser droog <luser.droog@gmail.com> - 2017-03-20 07:59 -0700
Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-19 10:57 -0400
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 16:14 +0000
Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-19 15:53 -0400
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 20:37 +0000
Re: Array allocated on stack or heap Jean-Marc Bourguet <jm@bourguet.org> - 2017-03-19 23:09 +0100
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 22:38 +0000
Re: Array allocated on stack or heap Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-19 16:21 -0700
Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-20 16:18 +1300
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 11:06 +0100
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 11:00 +0100
Re: Array allocated on stack or heap supercat@casperkitty.com - 2017-03-19 08:53 -0700
Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 16:11 -0400
Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-17 13:35 -0700
Re: Array allocated on stack or heap Chad <cdalten@gmail.com> - 2017-03-17 14:00 -0700
Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 23:57 +0100
Re: Array allocated on stack or heap Ian Collins <ian-news@hotmail.com> - 2017-03-18 12:42 +1300
Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-18 00:45 +0100
Re: Array allocated on stack or heap Chad <cdalten@gmail.com> - 2017-03-18 14:17 -0700
Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-19 19:21 +0100
Re: Array allocated on stack or heap already5chosen@yahoo.com - 2017-03-19 15:00 -0700
Re: Array allocated on stack or heap BartC <bc@freeuk.com> - 2017-03-19 22:16 +0000
Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-19 23:57 +0100
Re: Array allocated on stack or heap Keith Thompson <kst-u@mib.org> - 2017-03-19 16:15 -0700
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-20 12:24 +0100
Re: Array allocated on stack or heap scott@slp53.sl.home (Scott Lurndal) - 2017-03-20 13:24 +0000
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 13:21 +0100
Re: Array allocated on stack or heap John Bode <jfbode1029@gmail.com> - 2017-03-17 14:30 -0700
Re: Array allocated on stack or heap jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-17 23:59 +0100
Re: Array allocated on stack or heap Jerry Stuckle <jstucklex@attglobal.net> - 2017-03-17 21:02 -0400
Re: Array allocated on stack or heap David Brown <david.brown@hesbynett.no> - 2017-03-19 13:26 +0100
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-19 13:38 +0000 |
| Message-ID | <oam1fc$m5k$1@dont-email.me> |
| In reply to | #106486 |
On 19/03/2017 13:10, GOTHIER Nathan wrote: > On Sun, 19 Mar 2017 12:12:25 +0000 > BartC <bc@freeuk.com> wrote: >> Anyone notice an obvious way that this mess could be tidied up? > > I'm afraid only the Doctor Who could fix the C timeline. :o) > > Can you just remind us how old is C compared to the other languages you considered? > How old it is now, or how old it was when machines where already starting to move towards 8-16-32 bits? (With not very long odds on -64 bits being next.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-03-19 14:49 +0100 |
| Message-ID | <20170319144923.90c37a2a759d446ad85869db@gmail.com> |
| In reply to | #106492 |
On Sun, 19 Mar 2017 13:38:32 +0000 BartC <bc@freeuk.com> wrote: > How old it is now, or how old it was when machines where already > starting to move towards 8-16-32 bits? (With not very long odds on -64 > bits being next.) Nobody would like to demolish the foundation of his house to fix a bad architecture because it is as expensive to rebuild a new one with a significant loss of value. Unfortunately, the latest programming languages don't have the conciseness of C.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2017-03-20 07:59 -0700 |
| Message-ID | <2528284e-7440-47b1-8b76-874027bbc317@googlegroups.com> |
| In reply to | #106493 |
On Sunday, March 19, 2017 at 8:51:42 AM UTC-5, GOTHIER Nathan wrote: > On Sun, 19 Mar 2017 13:38:32 +0000 > BartC <bc@freeuk.com> wrote: > > > How old it is now, or how old it was when machines where already > > starting to move towards 8-16-32 bits? (With not very long odds on -64 > > bits being next.) > > Nobody would like to demolish the foundation of his house to fix a bad > architecture because it is as expensive to rebuild a new one with a significant > loss of value. Unfortunately, the latest programming languages don't have the > conciseness of C. https://codegolf.meta.stackexchange.com/a/7865/2381
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-19 10:57 -0400 |
| Message-ID | <oam639$otl$1@jstuckle.eternal-september.org> |
| In reply to | #106475 |
On 3/19/2017 8:12 AM, BartC wrote: > On 19/03/2017 11:30, David Brown wrote: >> On 18/03/17 00:12, jacobnavia wrote: > >> These "weird, small circuits" are the dominant type of processor. There >> are vastly more small, limited microcontrollers around than x86 or PPC >> processors. >> >> I am happy to agree that most C programmers will deal only with systems >> that have a single simple stack (per thread). I just like to make it >> clear that this is not the only way C is implemented - there are very >> common, real-world C implementations that have no stack or make minimal >> use of a stack. This is not just a hypothetical case, or very rare or >> unusual devices. > > > This has been discussed a few times but is it right that a language like > C should be permanently crippled, so that it can continue to work on > these tiny or oddball processors that can barely be termed computers. Or > should it be split? > <snip> Those "tiny or oddball processors" run the world. There are many times the number of them than there are x86 or PPC processors. A more appropriate question would be "Should C be permanently crippled so that it can continue to operate on x86 and PPC chips rather than these processors which run the world?". -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-19 16:14 +0000 |
| Message-ID | <oamajh$97c$1@dont-email.me> |
| In reply to | #106495 |
On 19/03/2017 14:57, Jerry Stuckle wrote: > On 3/19/2017 8:12 AM, BartC wrote: >> On 19/03/2017 11:30, David Brown wrote: >>> On 18/03/17 00:12, jacobnavia wrote: >> >>> These "weird, small circuits" are the dominant type of processor. There >>> are vastly more small, limited microcontrollers around than x86 or PPC >>> processors. >>> >>> I am happy to agree that most C programmers will deal only with systems >>> that have a single simple stack (per thread). I just like to make it >>> clear that this is not the only way C is implemented - there are very >>> common, real-world C implementations that have no stack or make minimal >>> use of a stack. This is not just a hypothetical case, or very rare or >>> unusual devices. >> >> >> This has been discussed a few times but is it right that a language like >> C should be permanently crippled, so that it can continue to work on >> these tiny or oddball processors that can barely be termed computers. Or >> should it be split? >> > <snip> > > Those "tiny or oddball processors" run the world. There are many times > the number of them than there are x86 or PPC processors. So? Even more reason for them to have their own dedicated language with even more specialised features. But a better measure would be how many lines of code (and therefore how much coding, debugging and maintenance is involved) run on such devices, compared with x86, ARM etc. > A more appropriate question would be "Should C be permanently crippled > so that it can continue to operate on x86 and PPC chips rather than > these processors which run the world?". The problem is that it becomes impossible to talk about a 'stack' (either hardware or emulated) because some device doesn't have one at all. You can't disregard padding bits, because a weird device might still use them. You can't assume there are 8 bits in a char, because some DSP might use more. The widths and relative sizes of the basic types, I've already covered. The language model is just too open-ended. This might be fine for a higher-level language, but C is supposed to be low-level. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-19 15:53 -0400 |
| Message-ID | <oamndf$nsd$1@jstuckle.eternal-september.org> |
| In reply to | #106497 |
On 3/19/2017 12:14 PM, BartC wrote: > On 19/03/2017 14:57, Jerry Stuckle wrote: >> On 3/19/2017 8:12 AM, BartC wrote: >>> On 19/03/2017 11:30, David Brown wrote: >>>> On 18/03/17 00:12, jacobnavia wrote: >>> >>>> These "weird, small circuits" are the dominant type of processor. >>>> There >>>> are vastly more small, limited microcontrollers around than x86 or PPC >>>> processors. >>>> >>>> I am happy to agree that most C programmers will deal only with systems >>>> that have a single simple stack (per thread). I just like to make it >>>> clear that this is not the only way C is implemented - there are very >>>> common, real-world C implementations that have no stack or make minimal >>>> use of a stack. This is not just a hypothetical case, or very rare or >>>> unusual devices. >>> >>> >>> This has been discussed a few times but is it right that a language like >>> C should be permanently crippled, so that it can continue to work on >>> these tiny or oddball processors that can barely be termed computers. Or >>> should it be split? >>> >> <snip> >> >> Those "tiny or oddball processors" run the world. There are many times >> the number of them than there are x86 or PPC processors. > > So? Even more reason for them to have their own dedicated language with > even more specialised features. > Sure. Then we can drop C for the x86 and PPC all together. > But a better measure would be how many lines of code (and therefore how > much coding, debugging and maintenance is involved) run on such devices, > compared with x86, ARM etc. > Probably 100 or more times the number as on x86 and PPC. There's a lot of code out there you never see. >> A more appropriate question would be "Should C be permanently crippled >> so that it can continue to operate on x86 and PPC chips rather than >> these processors which run the world?". > > The problem is that it becomes impossible to talk about a 'stack' > (either hardware or emulated) because some device doesn't have one at all. > So? Not a deal. > You can't disregard padding bits, because a weird device might still use > them. You can't assume there are 8 bits in a char, because some DSP > might use more. The widths and relative sizes of the basic types, I've > already covered. > No, you can't - in any language. And I've never had a problem with different sizes of char - what problems have you found? > The language model is just too open-ended. This might be fine for a > higher-level language, but C is supposed to be low-level. > Its open-endedness is exactly what makes it such a great language. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-19 20:37 +0000 |
| Message-ID | <oamq0k$2ci$1@dont-email.me> |
| In reply to | #106510 |
On 19/03/2017 19:53, Jerry Stuckle wrote:
> On 3/19/2017 12:14 PM, BartC wrote:
>> The language model is just too open-ended. This might be fine for a
>> higher-level language, but C is supposed to be low-level.
>>
>
> Its open-endedness is exactly what makes it such a great language.
Yeah, that's why its type model for example - of those five ill-defined
integer types - has been copied by Java, C#, Go and Rust. Oh wait...
Seriously, you really think having a byte-type which can be anything
from 8 to 64 bits wide is a great idea?
So that when you create an array of struct {char r,g,b;}, each element
might be from 3 to 24 or more bytes wide. And each char could have an
intensity value from 0 to 255, or maybe -128 to 127, or maybe 0 to
16777215 or -32768 to 32767. Is that what you mean by 'open-ended' being
so great, having absolutely no control over your types?
Or you might define it as struct {uint8_t r,g,b;}, but in that case,
it's not quite so open-ended is it? You're admitting that the regular
'char' type is not fit for purpose.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2017-03-19 23:09 +0100 |
| Message-ID | <87o9wwvrz9.fsf@news.bourguet.org> |
| In reply to | #106515 |
BartC <bc@freeuk.com> writes: > On 19/03/2017 19:53, Jerry Stuckle wrote: >> On 3/19/2017 12:14 PM, BartC wrote: > >>> The language model is just too open-ended. This might be fine for a >>> higher-level language, but C is supposed to be low-level. >>> >> >> Its open-endedness is exactly what makes it such a great language. > > Yeah, that's why its type model for example - of those five ill-defined > integer types - has been copied by Java, C#, Go and Rust. Oh wait... You may consider that it is not a wise choice nowadays. I'm not well versed enough in the embedded system world to have an opinion: 8-bit byte seems to be universal, but word-addressable and non power-of-two words were apparently still relevant a few years ago and may still be. That's probably not a factor for Java and C#; for Go and even more Rust who want to be better C may have lef by that choice some application domains to C. But to be fair when criticizing a design -- as opposed to just ranting without any other goal than evacuating some frustration -- you need to look at the situation when the choices were made. Considering that the second and third architecture to which C was ported were IBM 360 (that architecture for which the usual calling convention mandated that you dynamically allocate your stack frame if you want to allow recursion -- I don't know if it is still true for the 64 extension) and Honeywell 635 (a word adressable, 36 bit machine, at least it was 2's complement), you can hardly make fault to the language to have taken account for such, nowadays uncommon, characteristic. > Seriously, you really think having a byte-type which can be anything from 8 > to 64 bits wide is a great idea? It was the unquestioned common practice of the time. More, even with insight but having used C with an implementation which had 9-bit bytes, it was the right choice for the time. Java is the first language I'm aware of which defined type sizes without leaving them to the implementation choice. It was not a choice thinkable in the 70's, and in the 80's it would still have cut important part of the installed park or led to dialects ignoring that constraint (the C implementation which had 9-bit bytes had also modes with 7 and, IIRC, 6-bit bytes -- you can state what you want in the document describing your language, that may be and will be ignored by the implementers if that makes too little sense for their targets and after that you'll have to take their choice into account if their targets are of any importance -- cfr Microsoft coming years after everybody had standardized on LP64 and using LLP64). Yours -- Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-19 22:38 +0000 |
| Message-ID | <oan14a$qh4$1@dont-email.me> |
| In reply to | #106519 |
On 19/03/2017 22:09, Jean-Marc Bourguet wrote: > BartC <bc@freeuk.com> writes: > >> On 19/03/2017 19:53, Jerry Stuckle wrote: >>> On 3/19/2017 12:14 PM, BartC wrote: >> >>>> The language model is just too open-ended. This might be fine for a >>>> higher-level language, but C is supposed to be low-level. >>>> >>> >>> Its open-endedness is exactly what makes it such a great language. >> >> Yeah, that's why its type model for example - of those five ill-defined >> integer types - has been copied by Java, C#, Go and Rust. Oh wait... > > You may consider that it is not a wise choice nowadays. I'm not well > versed enough in the embedded system world to have an opinion: 8-bit byte > seems to be universal, but word-addressable and non power-of-two words were > apparently still relevant a few years ago and may still be. That's > probably not a factor for Java and C#; for Go and even more Rust who want > to be better C may have lef by that choice some application domains to C. > > But to be fair when criticizing a design -- as opposed to just ranting > without any other goal than evacuating some frustration -- you need to look > at the situation when the choices were made. Considering that the second > and third architecture to which C was ported were IBM 360 (that > architecture A byte-addressable 32-bit machine IIRC. for which the usual calling convention mandated that you > dynamically allocate your stack frame if you want to allow recursion -- I > don't know if it is still true for the 64 extension) and Honeywell 635 (a > word adressable, 36 bit machine, at least it was 2's complement), you can > hardly make fault to the language to have taken account for such, nowadays > uncommon, characteristic. > >> Seriously, you really think having a byte-type which can be anything from 8 >> to 64 bits wide is a great idea? > > It was the unquestioned common practice of the time. More, even with > insight but having used C with an implementation which had 9-bit bytes, it > was the right choice for the time. Java is the first language I'm aware of > which defined type sizes without leaving them to the implementation choice. > It was not a choice thinkable in the 70's, and in the 80's it would still > have cut important part of the installed park or led to dialects ignoring > that constraint (the C implementation which had 9-bit bytes had also modes > with 7 and, IIRC, 6-bit bytes -- you can state what you want in the > document describing your language, that may be and will be ignored by the > implementers if that makes too little sense for their targets and after > that you'll have to take their choice into account if their targets are of > any importance -- cfr Microsoft coming years after everybody had > standardized on LP64 and using LLP64). I've coded on 36-bit equipment where characters might have been packed 6- or 7-bit values. (I did my first language implementation on it; I wish I could remember what I did about characters. But I know they were a nuisance to deal with generally.) But that was a /very/ long time ago. Not long after, I also did a bit of embedded stuff, but that was all 8-bit-addressable on the devices I used. The world now is predominantly 8-16-32-64 bits (no matter is there are more 7-bit devices by number or whatever). The trouble is, someone brings a device, which is not really a general purpose computer all, with odd-sized registers and all sorts of strange features. But because it is programmable, they manage to get a C compiler to produce code for it. That means that because C can target such strange processors, the language is not allowed to make any assumptions that would be false for those devices. They are holding it back. That's why it is refreshing to see a reference for another language and see 'byte - 8 bits wide', or 'int - 32 bits wide'. Always, and totally inherent within the language rather than bolted on to one that wouldn't be fazed if a byte had 13 bits plus 9 padding bits. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-03-19 16:21 -0700 |
| Message-ID | <1a104d1a-a11b-4873-a92e-2f6869179b90@googlegroups.com> |
| In reply to | #106521 |
On Sunday, March 19, 2017 at 10:38:53 PM UTC, Bart wrote: > > The trouble is, someone brings a device, which is not really a general > purpose computer all, with odd-sized registers and all sorts of strange > features. But because it is programmable, they manage to get a C > compiler to produce code for it. > > That means that because C can target such strange processors, the > language is not allowed to make any assumptions that would be false for > those devices. They are holding it back. > I think that's the point. Even weird architectures still need logic like if (temperature > set_temperature) turndownheater(); It's easier in C than in either raw assembly or some weird processor scripting language. But to implement Turndownheater() you probably have to write something to an absolute address which is in fact a memory- mapped IO port. C does that as well, but it's inherently non-portable #define IOPOORT1 0x8004 and so on. The important thing for higher level code is that functions (that operate on bits) be separated from procedures (things which do IO), and that an integer type be large enough to index any memory. That's all you really need to knock out functions which can be as simple or as sophisticated as you wish. We also really need a slightly bigger smidgeon of object-orientation than we have for stream objects, which is the high-level interface to most IO, though not addressing a raster-graphics screen or outputting audio.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-20 16:18 +1300 |
| Message-ID | <ej900kFljunU4@mid.individual.net> |
| In reply to | #106521 |
On 03/20/17 11:38 AM, BartC wrote: > > That's why it is refreshing to see a reference for another language and > see 'byte - 8 bits wide', or 'int - 32 bits wide'. Always, and totally > inherent within the language rather than bolted on to one that wouldn't > be fazed if a byte had 13 bits plus 9 padding bits. If you want guaranteed fixed width type, you know where to find them... If you want you add environmental requirements over and above standard C, you can. Look at POSIX. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-20 11:06 +0100 |
| Message-ID | <oao9ec$s30$1@dont-email.me> |
| In reply to | #106519 |
On 19/03/17 23:09, Jean-Marc Bourguet wrote: > BartC <bc@freeuk.com> writes: > >> On 19/03/2017 19:53, Jerry Stuckle wrote: >>> On 3/19/2017 12:14 PM, BartC wrote: >> >>>> The language model is just too open-ended. This might be fine for a >>>> higher-level language, but C is supposed to be low-level. >>>> >>> >>> Its open-endedness is exactly what makes it such a great language. >> >> Yeah, that's why its type model for example - of those five ill-defined >> integer types - has been copied by Java, C#, Go and Rust. Oh wait... > > You may consider that it is not a wise choice nowadays. I'm not well > versed enough in the embedded system world to have an opinion: 8-bit byte > seems to be universal, but word-addressable and non power-of-two words were > apparently still relevant a few years ago and may still be. That's > probably not a factor for Java and C#; for Go and even more Rust who want > to be better C may have lef by that choice some application domains to C. The most common modern architectures that don't fit the nice 8-bit char, and power-of-two types, are DSPs. There a many popular DSP architectures that have 16-bit or even 32-bit char. There are also some that have 8-bit char and 24-bit "int", especially for audio processing. And there are a few that have even weirder sizes - I have seen DSP families that have 10-bit, 12-bit, or 14-bit char sizes. But such odd sizes are definitely on the decline. DSP programming in general is becoming more of a niche task.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-20 11:00 +0100 |
| Message-ID | <oao92g$qs0$1@dont-email.me> |
| In reply to | #106497 |
On 19/03/17 17:14, BartC wrote: > On 19/03/2017 14:57, Jerry Stuckle wrote: >> On 3/19/2017 8:12 AM, BartC wrote: >>> On 19/03/2017 11:30, David Brown wrote: >>>> On 18/03/17 00:12, jacobnavia wrote: >>> >>>> These "weird, small circuits" are the dominant type of processor. >>>> There >>>> are vastly more small, limited microcontrollers around than x86 or PPC >>>> processors. >>>> >>>> I am happy to agree that most C programmers will deal only with systems >>>> that have a single simple stack (per thread). I just like to make it >>>> clear that this is not the only way C is implemented - there are very >>>> common, real-world C implementations that have no stack or make minimal >>>> use of a stack. This is not just a hypothetical case, or very rare or >>>> unusual devices. >>> >>> >>> This has been discussed a few times but is it right that a language like >>> C should be permanently crippled, so that it can continue to work on >>> these tiny or oddball processors that can barely be termed computers. Or >>> should it be split? >>> >> <snip> >> >> Those "tiny or oddball processors" run the world. There are many times >> the number of them than there are x86 or PPC processors. > > So? Even more reason for them to have their own dedicated language with > even more specialised features. > C allows implementation extensions to give these specialised features - and pretty much every compiler targeting embedded systems will have some extensions. These are typically not easily transferred from one target to another because the targets differ - thus a common standard here would not help. And for extensions which /can/ easily be applied to a range of targets, many compiler vendors have settled on gcc versions as a "de facto" standard. Attempts have been made to make additional standards for embedded C - they have mostly failed by being too bureaucratic, too loosely specified, too slow to match the pace of user needs, and generally missing the point. > But a better measure would be how many lines of code (and therefore how > much coding, debugging and maintenance is involved) run on such devices, > compared with x86, ARM etc. That is a /different/ measure, but not necessarily a better one. You could also consider how much time or money is spent on the code, which will give you a different measure again (there are development styles where 10 lines of code per developer per week is considered fast). > >> A more appropriate question would be "Should C be permanently crippled >> so that it can continue to operate on x86 and PPC chips rather than >> these processors which run the world?". > > The problem is that it becomes impossible to talk about a 'stack' > (either hardware or emulated) because some device doesn't have one at all. You can talk about a stack if you want. It might be a "logical" or "virtual" stack, but generally that's a perfectly good model. I can't think of any circumstances where it is relevant how this "virtual stack" is implemented - as a "real" stack, a linked-list of frames, or whatever. > > You can't disregard padding bits, because a weird device might still use > them. You can't assume there are 8 bits in a char, because some DSP > might use more. The widths and relative sizes of the basic types, I've > already covered. C programming can be roughly split into two types of code - portable code and non-portable code. When you are writing code that will work on a range of targets and compilers, you stick to a portable subset of C - basically, you stick to standards-defined behaviour or possibly additional standards such as Posix. When you are writing non-portable code, you can use compiler extensions, or knowledge of the target. The C standards are specifically set up to support both types of programming. For most of my programming, I /can/ assume that there are 8 bits in a char - and that is a requirement limiting the portability of my code. If I am writing code that doesn't need that assumption, then I don't make the assumption and the code is more portable. > > The language model is just too open-ended. This might be fine for a > higher-level language, but C is supposed to be low-level. > C is supposed to cover a wide range of needs - and it does.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-03-19 08:53 -0700 |
| Message-ID | <22e13ed3-4cd2-4345-b309-80d6f1c1844f@googlegroups.com> |
| In reply to | #106475 |
On Sunday, March 19, 2017 at 7:12:32 AM UTC-5, Bart wrote: > This has been discussed a few times but is it right that a language like > C should be permanently crippled, so that it can continue to work on > these tiny or oddball processors that can barely be termed computers. Or > should it be split? If one recognizes that different implementations should be suitable for different purposes, if implementations use freedom granted by the Standard so as to behave in whatever fashion is most suitable for their intended purpose, and implementation writers are clear about what the intended purpose of their implementations *is*, there's no need to cripple anything. On the other hand, officially recognizing optional features would be better than relying upon judgment and common sense, since it would make it possible to define a category of programs which won't work on all implementations, but will fail in defined fashion (likely at compile/build time) on implementations where they don't work.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-03-17 16:11 -0400 |
| Message-ID | <oahfni$65u$2@jstuckle.eternal-september.org> |
| In reply to | #106383 |
On 3/17/2017 3:45 PM, jacobnavia wrote: > Le 17/03/2017 à 20:15, John Bode a écrit : >> The real-world implementations I know of would try to place it on the >> runtime stack, but that's strictly a function of the implementation, not >> the language definition. All the language definition specifies is *when* >> and for how long memory is to be set aside for the object, not *where*. > > The language definition defines a logical stack of nested scopes. > > You enter a scope and push the old contents of the workspace to make > place for a new scope with new data. You do your calculations and exit > the scope with (or without) result. You pop the old context and you > continue. > > You can enter a scope and exit it in a stack-like manner. Now, it is > obvious since almost all CPUs have a machine stack, that the best thing > to do is to implement the C stack using the machine's stack pointer. > > Obviously. > And incorrect. There are lots of processors out there which do not have a stack. IBM mainframes, for instance, but some processors used in control and embedded systems don't, either. > I never thought somebody would discuss such obvious facts. > > The C language does imply a stack, and most implementations use the > machine stack since it is built for doing exactly that: a stack. > > Where in the standard does it say there is a stack? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-17 13:35 -0700 |
| Message-ID | <ln37ebfxpq.fsf@kst-u.example.com> |
| In reply to | #106383 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 17/03/2017 à 20:15, John Bode a écrit :
>> The real-world implementations I know of would try to place it on the
>> runtime stack, but that's strictly a function of the implementation, not
>> the language definition. All the language definition specifies is *when*
>> and for how long memory is to be set aside for the object, not *where*.
>
> The language definition defines a logical stack of nested scopes.
>
> You enter a scope and push the old contents of the workspace to make
> place for a new scope with new data. You do your calculations and exit
> the scope with (or without) result. You pop the old context and you
> continue.
>
> You can enter a scope and exit it in a stack-like manner. Now, it is
> obvious since almost all CPUs have a machine stack, that the best thing
> to do is to implement the C stack using the machine's stack pointer.
>
> Obviously.
>
> I never thought somebody would discuss such obvious facts.
>
> The C language does imply a stack, and most implementations use the
> machine stack since it is built for doing exactly that: a stack.
One more time.
The word "stack" is being used in two different senses here (and the C
standard doesn't use it in either sense).
Storage for objects with automatic storage duration is allocated in a
stack-like first-in last-out manner. (C11 threading complicates this a
bit, making it possible to call func0(), then call func1(), then return
from func0(), then return from func1(). I haven't taken the time to
look into how the standard addresses this.)
Most, but not all, implementations handle this by using a "hardware
stack", where stack allocations are contiguous in memory, grow in a
particular direction, and are typically managed via a CPU register known
as the "stack pointer". At least one implementation that's been cited
here instead allocates automatic objects in a manner that doesn't place
them consecutively or grow the "stack" in a particular direction;
instead it does something similar to malloc() on each function call.
What John wrote is perfectly correct. What you wrote is also correct,
apart from your ignoring alternatives. I fail to understand why you
feel the need to jump in and act as if you were correcting what John
wrote.
Do you actually disagree with anything John wrote?
--
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]
| From | Chad <cdalten@gmail.com> |
|---|---|
| Date | 2017-03-17 14:00 -0700 |
| Message-ID | <e997eac7-f25b-4401-8497-cd1206935a1c@googlegroups.com> |
| In reply to | #106390 |
The one machine that I have uses a register based stack instead of a regular stack. As a result, there is really no such thing as pushing and popping numbers.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-17 23:57 +0100 |
| Message-ID | <oahpfh$904$1@dont-email.me> |
| In reply to | #106392 |
Le 17/03/2017 à 22:00, Chad a écrit :
> The one machine that I have uses a register based stack instead of a regular stack. As a result, there is really no such thing as pushing and popping numbers.
>
Most machines have up to 32 registers, maybe some have more.
So, your register stack has place for 32 quantities, rather short for
any serious problem or serious C software.
Then, you will agree with me, there is a portion of memory that must be
addressed in a stack like fashion each time you make a function call,
for instance.
Suppose this program:
int fn1(int a)
{
return 25.87/3.14159 + a;
}
int main(void)
{
int a = 67;
a += fn(1);
printf("result=%d¡n",a);
}
When you enter the expression fn(1), and inside the fn function, a is
assigned the value 1. The old value is pushed into the stack and is
inaccessible until the called function pops the stack and returns into
the main function with a result of the calculations done in the inner scope.
This result is added to the old value of a that was popped when the
function returned. We agree that within main the variable "a" has
nothing to do with the value it had within "fn()".
Calling a procedure or function means pushing into a conceptual stack
all the values held by the current scope, operation that is balanced by
a pop when the function returns.
By the way your machine with a dedicated register stack is caching the
top of this stack into machine registers, but that doesn't change the
conceptual form of the data processing structure you are using: a stack.
And what is the name of your mysterious machine?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-03-18 12:42 +1300 |
| Message-ID | <ej3ajoFhe9iU18@mid.individual.net> |
| In reply to | #106397 |
On 03/18/17 11:57 AM, jacobnavia wrote:
>
> Most machines have up to 32 registers, maybe some have more.
>
> So, your register stack has place for 32 quantities, rather short for
> any serious problem or serious C software.
>
> Then, you will agree with me, there is a portion of memory that must be
> addressed in a stack like fashion each time you make a function call,
> for instance.
>
> Suppose this program:
>
> int fn1(int a)
> {
> return 25.87/3.14159 + a;
> }
>
>
> int main(void)
> {
> int a = 67;
> a += fn(1);
> printf("result=%d¡n",a);
> }
>
> When you enter the expression fn(1), and inside the fn function, a is
> assigned the value 1. The old value is pushed into the stack and is
> inaccessible until the called function pops the stack and returns into
> the main function with a result of the calculations done in the inner scope.
Have a look a RISC machines such as Sparc that use overlapping register
windows. In your example 'a' could be in a register that is an output
register in main() and an input register in f(). Obviously when the a
function has more parameters than there are overlapping registers or a
call stack is deeper than the number of overlapping sets, a "normal"
stack has to be used.
There's a good explanation here:
http://www.mathcs.emory.edu/~cheung/Courses/255/Syllabus/8-SPARC/save+restore.html
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-03-18 00:45 +0100 |
| Message-ID | <oahs90$jo3$1@dont-email.me> |
| In reply to | #106408 |
Le 18/03/2017 à 00:42, Ian Collins a écrit : > Obviously when the a function has more parameters than there are > overlapping registers or a call stack is deeper than the number of > overlapping sets, a "normal" stack has to be used. That is exactly what I was saying.
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web