Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #127943 > unrolled thread
| Started by | bartc <bc@freeuk.com> |
|---|---|
| First post | 2018-03-17 16:07 +0000 |
| Last post | 2018-03-21 12:19 +0000 |
| Articles | 20 on this page of 125 — 24 participants |
Back to article view | Back to comp.lang.c
Dropping C bartc <bc@freeuk.com> - 2018-03-17 16:07 +0000
Re: Dropping C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-18 00:41 +0800
Re: Dropping C Richard Damon <Richard@Damon-Family.org> - 2018-03-17 19:54 -0400
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-18 13:19 +1300
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 02:42 -0700
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-18 01:28 +0000
Re: Dropping C Richard Damon <Richard@Damon-Family.org> - 2018-03-17 21:41 -0400
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-18 11:25 +0000
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 04:33 -0700
Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-19 00:05 +0100
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 00:24 +0000
Re: Dropping C Richard Damon <Richard@Damon-Family.org> - 2018-03-18 21:15 -0400
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 19:00 -0700
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-19 14:04 +0100
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-19 06:08 -0700
Re: Dropping C supercat@casperkitty.com - 2018-03-19 14:29 -0700
Re: Dropping C Noob <root@127.0.0.1> - 2018-03-19 14:34 +0100
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-19 06:39 -0700
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-19 15:17 +0100
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 15:03 +0000
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-19 15:36 +0000
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 17:01 +0000
Re: Dropping C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-03-19 12:14 -0600
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 19:15 +0000
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-20 08:20 +1300
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 20:47 +0000
Re: Dropping C Lowell Gilbert <lgusenet@be-well.ilk.org> - 2018-03-19 18:00 -0400
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 22:17 +0000
Re: Dropping C Reinhardt Behm <rbehm@hushmail.com> - 2018-03-20 09:34 +0800
Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-21 07:54 +0100
Re: Dropping C Robert Wessel <robertwessel2@yahoo.com> - 2018-03-21 04:10 -0500
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-21 11:08 +0000
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-21 11:18 +0000
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-21 05:28 -0700
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-21 12:13 +0000
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-21 12:26 +0000
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-21 15:55 +0000
Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-21 20:15 +0100
Re: Dropping C Keith Thompson <kst-u@mib.org> - 2018-03-21 12:45 -0700
Re: Dropping C supercat@casperkitty.com - 2018-03-21 13:46 -0700
Killfiles (Was: Dropping C) gazelle@shell.xmission.com (Kenny McCormack) - 2018-03-21 21:42 +0000
Re: Killfiles (Was: Dropping C) Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-22 04:22 -0700
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-21 20:21 +0000
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-21 22:21 -0700
Re: Dropping C Reinhardt Behm <rbehm@hushmail.com> - 2018-03-20 09:32 +0800
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 10:01 +1300
Re: Dropping C luser droog <luser.droog@gmail.com> - 2018-03-20 16:01 -0700
Re: Dropping C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-03-19 13:41 -0600
Re: Dropping C luser droog <luser.droog@gmail.com> - 2018-03-19 12:52 -0700
Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-19 20:15 +0000
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-19 20:38 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-19 22:00 +0100
Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 01:45 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-20 03:05 +0100
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 21:09 +0000
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-20 18:26 +1300
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 10:58 +0000
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-20 14:22 +0100
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-20 13:58 +0000
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-20 17:14 +0100
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 16:31 +0000
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-20 17:14 +0000
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 07:31 +1300
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 18:51 +0000
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 08:01 +1300
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-20 19:03 +0000
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 19:22 +0000
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 08:25 +1300
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-20 19:33 +0000
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-21 09:34 +1300
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-20 19:49 +0000
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-21 11:27 +0100
Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 01:27 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-19 17:03 +0100
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-19 23:13 +0100
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-20 00:23 +0100
Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 00:55 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-20 02:29 +0100
Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 02:04 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-20 03:31 +0100
Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-21 20:18 +0100
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-21 21:32 +0100
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-21 20:52 +0000
Re: Dropping C supercat@casperkitty.com - 2018-03-21 14:38 -0700
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-21 23:08 +0100
Re: Dropping C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-22 13:37 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 15:41 +0100
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-22 14:58 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 17:37 +0100
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-22 17:09 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 18:27 +0100
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-22 17:35 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 18:46 +0100
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-22 18:22 +0000
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-22 19:38 +0100
Re: Dropping C jameskuyper@verizon.net - 2018-03-22 12:19 -0700
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-22 20:23 +0000
Re: Dropping C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-03-23 06:10 -0700
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-23 14:54 +0100
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-23 16:55 +0100
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-23 17:46 +0100
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-24 02:50 +0100
Re: Dropping C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-24 02:54 +0100
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-22 16:43 +0000
Re: Dropping C Keith Thompson <kst-u@mib.org> - 2018-03-22 10:39 -0700
Re: Dropping C Robert Wessel <robertwessel2@yahoo.com> - 2018-03-22 11:47 -0500
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-24 00:59 -0700
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 15:07 +0000
Re: Dropping C scott@slp53.sl.home (Scott Lurndal) - 2018-03-19 15:37 +0000
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 17:16 +0000
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-19 20:30 +0000
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-19 21:24 +0000
Re: Dropping C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-19 23:06 +0000
Re: Dropping C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-20 14:04 +0000
Re: Dropping C supercat@casperkitty.com - 2018-03-19 15:32 -0700
Re: Dropping C Robert Wessel <robertwessel2@yahoo.com> - 2018-03-19 19:03 -0500
Re: Dropping C Spiros Bousbouras <spibou@gmail.com> - 2018-03-20 02:13 +0000
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-20 14:25 +0100
Re: Dropping C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-21 18:36 +0100
Re: Dropping C David Brown <david.brown@hesbynett.no> - 2018-03-19 23:33 +0100
Re: Dropping C supercat@casperkitty.com - 2018-03-19 16:34 -0700
Re: Dropping C asetofsymbols@gmail.com - 2018-03-20 00:58 -0700
Re: Dropping C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-20 01:10 -0700
Re: Dropping C Ian Collins <ian-news@hotmail.com> - 2018-03-19 14:25 +1300
Re: Dropping C bartc <bc@freeuk.com> - 2018-03-21 12:19 +0000
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-17 16:07 +0000 |
| Subject | Dropping C |
| Message-ID | <O2brC.21320$dj4.9265@fx07.am4> |
On 16/03/2018 01:36, bartc wrote: [Linking to my C compiler project] > Creating a one file C source is proving troublesome As well as abandoning support for one-file C sources, I've decided for now to also drop support for generating any C source at all. I've only just realised that's making life more difficult rather than simpler: * My IDE supports 11 combinations of C compilers [including 32/64-bit variations], which all work a little differently. Generating C that will keep all happy is rare * They all have different criteria for what constitute errors and warnings * Generating code for a large project that is free of warnings is difficult (and there will always be someone who will ramp it up further). On some compilers, impossible. * Working on my C compiler has drawn me in to a world of horrendous looking configure scripts, makefiles, system header files, and source files full of conditional code and dense macros. (For debugging certain apps, I've resorted to working with preprocessed code, so that everything is just there, rather than traipsing all over the source directory and having to keep looking up macro.) * There's also the risk that any code I write might be assumed to be undefined behaviour, and turned into something else by a compiler. * There's the problem with struct packing, where I need to know /exactly/ how a C compiler might deal with it. * And I can't use some original source features I want because C, or some compilers, will have difficult. Removing the intermediate C stage cuts right through all these problems. (The cost: having to provide my own support for some targets. Not benefiting by passing code through an optimising C compiler.) > I'll put some docs on Github (https://github.com/bartg/langs) when I > have time (it doesn't say much at the moment). The C compiler project remains as a curiosity. It can compile my C dialect with no problem, for new code, or for generated code (now no longer used), but it can have a hard time if thrown an arbitrary open source app. Maintaining it seriously is a huge effort. Anyway, it is still there as a binary, but I don't know how buildable source can be made available. -- bartc
[toc] | [next] | [standalone]
| From | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| Date | 2018-03-18 00:41 +0800 |
| Message-ID | <p8jgfa$81a$2@toylet.eternal-september.org> |
| In reply to | #127943 |
We don't usually write source codes that could be compiled by ALL C compilers. We usually work with the most-used platform. On 18/3/2018 00:07, bartc wrote: > On 16/03/2018 01:36, bartc wrote: > > [Linking to my C compiler project] > .... > > The C compiler project remains as a curiosity. It can compile my C > dialect with no problem, for new code, or for generated code (now no > longer used), but it can have a hard time if thrown an arbitrary open > source app. Maintaining it seriously is a huge effort. > > Anyway, it is still there as a binary, but I don't know how buildable > source can be made available. -- @~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!! / v \ Simplicity is Beauty! /( _ )\ May the Force and farces be with you! ^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3 不借貸! 不詐騙! 不賭錢! 不援交! 不打交! 不打劫! 不自殺! 不求神! 請考慮綜援 (CSSA): http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-03-17 19:54 -0400 |
| Message-ID | <eVhrC.14428$xT.1940@fx13.iad> |
| In reply to | #127943 |
On 3/17/18 12:07 PM, bartc wrote: > On 16/03/2018 01:36, bartc wrote: > > [Linking to my C compiler project] > > > Creating a one file C source is proving troublesome > > As well as abandoning support for one-file C sources, I've decided for > now to also drop support for generating any C source at all. > > I've only just realised that's making life more difficult rather than > simpler: > > * My IDE supports 11 combinations of C compilers [including 32/64-bit > variations], which all work a little differently. Generating C that will > keep all happy is rare > > * They all have different criteria for what constitute errors and warnings > > * Generating code for a large project that is free of warnings is > difficult (and there will always be someone who will ramp it up > further). On some compilers, impossible. > > * Working on my C compiler has drawn me in to a world of horrendous > looking configure scripts, makefiles, system header files, and source > files full of conditional code and dense macros. > > (For debugging certain apps, I've resorted to working with > preprocessed code, so that everything is just there, rather than > traipsing all over the source directory and having to keep looking up > macro.) > > * There's also the risk that any code I write might be assumed to be > undefined behaviour, and turned into something else by a compiler. > > * There's the problem with struct packing, where I need to know > /exactly/ how a C compiler might deal with it. > > * And I can't use some original source features I want because C, or > some compilers, will have difficult. > > Removing the intermediate C stage cuts right through all these problems. > > (The cost: having to provide my own support for some targets. Not > benefiting by passing code through an optimising C compiler.) > > > > I'll put some docs on Github (https://github.com/bartg/langs) when I > > have time (it doesn't say much at the moment). > > The C compiler project remains as a curiosity. It can compile my C > dialect with no problem, for new code, or for generated code (now no > longer used), but it can have a hard time if thrown an arbitrary open > source app. Maintaining it seriously is a huge effort. > > Anyway, it is still there as a binary, but I don't know how buildable > source can be made available. > One fundamental issues with your goals is that you seem to want your code to be warning free, for all implementations and all warning settings. This is fundamentally an impossibility. The standard puts NO restrictions no the generation of "Warnings", all it talks about are "Diagnostics" (things the implementation is required to make some level of complaint about, that complaint might be what we call an Error, or might just be a Warning), and the implementation is allowed to make any other comments it wants (it must 'accept' strictly conforming code, but it is allowed to be vocal about holding its nose up at it). Practically, I have seen instances which would make it very hard if not impossible to get totally warning free code, as one implementation might suggest adding extra parenthesis to avoid possible confusion operator precedence, while if you add them another may complain that you have an unneeded parenthesis. A warning free requirement might make sense with a limited and specified set of compilers, which the code is regularly tested against. You also have a smaller issue with needing to know exactly how the compiler will generate certain things (like structs) and these are things that the standard doesn't precisely define, in part because it wants to allow freedom for implementations to generate efficient code. These are often specified in an ABI document, but that isn't normally in a form that readily can just be feed into an implementation, so if you need that sort of information you are going to need to digest it yourself, or generate code to interrogate the implementation.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-03-18 13:19 +1300 |
| Message-ID | <fh5pk8Fats7U1@mid.individual.net> |
| In reply to | #127958 |
On 03/18/2018 12:54 PM, Richard Damon wrote: > > One fundamental issues with your goals is that you seem to want your > code to be warning free, for all implementations and all warning > settings. This is fundamentally an impossibility. The standard puts NO > restrictions no the generation of "Warnings", all it talks about are > "Diagnostics" (things the implementation is required to make some level > of complaint about, that complaint might be what we call an Error, or > might just be a Warning), and the implementation is allowed to make any > other comments it wants (it must 'accept' strictly conforming code, but > it is allowed to be vocal about holding its nose up at it). > > Practically, I have seen instances which would make it very hard if not > impossible to get totally warning free code, as one implementation might > suggest adding extra parenthesis to avoid possible confusion operator > precedence, while if you add them another may complain that you have an > unneeded parenthesis. > > A warning free requirement might make sense with a limited and specified > set of compilers, which the code is regularly tested against. > > You also have a smaller issue with needing to know exactly how the > compiler will generate certain things (like structs) and these are > things that the standard doesn't precisely define, in part because it > wants to allow freedom for implementations to generate efficient code. > These are often specified in an ABI document, but that isn't normally in > a form that readily can just be feed into an implementation, so if you > need that sort of information you are going to need to digest it > yourself, or generate code to interrogate the implementation. I've kept everything because I agree with all of it... No sensible code generation scheme has those lofty goals. Regarding struct layout, there is also the not so small matter of interacting with any other parts of the host system or any third party libraries. If you don't follow the the host ABI, your code it pretty much isolated to its own sandbox. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-18 02:42 -0700 |
| Message-ID | <ca07a181-7095-4088-9efc-1df3cf24194d@googlegroups.com> |
| In reply to | #127959 |
On Saturday, March 17, 2018 at 5:19:29 PM UTC-7, Ian Collins wrote: > On 03/18/2018 12:54 PM, Richard Damon wrote: > > > > One fundamental issues with your goals is that you seem to want your > > code to be warning free, for all implementations and all warning > > settings. This is fundamentally an impossibility. The standard puts NO > > restrictions no the generation of "Warnings", all it talks about are > > "Diagnostics" (things the implementation is required to make some level > > of complaint about, that complaint might be what we call an Error, or > > might just be a Warning), and the implementation is allowed to make any > > other comments it wants (it must 'accept' strictly conforming code, but > > it is allowed to be vocal about holding its nose up at it). > > > > Practically, I have seen instances which would make it very hard if not > > impossible to get totally warning free code, as one implementation might > > suggest adding extra parenthesis to avoid possible confusion operator > > precedence, while if you add them another may complain that you have an > > unneeded parenthesis. > > > > A warning free requirement might make sense with a limited and specified > > set of compilers, which the code is regularly tested against. > > > > You also have a smaller issue with needing to know exactly how the > > compiler will generate certain things (like structs) and these are > > things that the standard doesn't precisely define, in part because it > > wants to allow freedom for implementations to generate efficient code. > > These are often specified in an ABI document, but that isn't normally in > > a form that readily can just be feed into an implementation, so if you > > need that sort of information you are going to need to digest it > > yourself, or generate code to interrogate the implementation. > > I've kept everything because I agree with all of it... No sensible code > generation scheme has those lofty goals. > > Regarding struct layout, there is also the not so small matter of > interacting with any other parts of the host system or any third party > libraries. If you don't follow the the host ABI, your code it pretty > much isolated to its own sandbox. > > -- > Ian. Melzzz has toned down the hundreds of self-serving, nonsense attacks he used to write but he's surely consistent in the honesty area. He uses puppets more now to produce those threads. Melzzz is the outcome of the reality that Maoists have been hired to take the lead in schooling young persons. It's not a coincidence that he is a mindless communist. But when the data were collected, it turns out by _that_ criteria, Melzzz was far more "neurotic" than even I imagined. Translation of Melzzz speak: Melzzz's "problem solving abilities" side tracked him from a module he insists does not exists that can be quickly Googled for this application. The only thing not working here is Melzzz. It was Melzzz who flooded Audra Moore's site thousands of times and denied it. I've worked in the retail industry for more than 30 years. I have worked with multinational corporations working with the military and police forces. Never were we ever directed not to pre-install any other OS. We sold AIX, Mac, Red Hat, and so forth alongside MS OSs very successfully. - Do not click this link! Michael Glasser: Prescott Computer Guy http://prescottcomputerguy.com http://www.5z8.info/dogs-being-eaten_g0w7hf_molotovcocktail Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-18 01:28 +0000 |
| Message-ID | <2hjrC.38651$%a5.4397@fx21.am4> |
| In reply to | #127958 |
On 17/03/2018 23:54, Richard Damon wrote: > On 3/17/18 12:07 PM, bartc wrote: >> As well as abandoning support for one-file C sources, I've decided for >> now to also drop support for generating any C source at all. >> * Generating code for a large project that is free of warnings is >> difficult (and there will always be someone who will ramp it up >> further). On some compilers, impossible. > One fundamental issues with your goals is that you seem to want your > code to be warning free, for all implementations and all warning > settings. This is fundamentally an impossibility. It doesn't seem impossible when I generate ASM code; the assembler is generally very quiet unless something is clearly wrong (and then the error is likely to be a compiler fault rather than application). But C compilers have minds of their own and they will complain about different things, even though IMO the code is correct, partly because it has already been verified with my compiler. But I don't have full confidence these days that the C compiler will do what I tell it. Myself, I'm not too worried about most warnings, but people who have tried to compile my generated C have complained about them. (Note that my C compiler doesn't report warnings at all, only errors, but perhaps it doesn't count.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-03-17 21:41 -0400 |
| Message-ID | <mtjrC.7043$ob5.812@fx25.iad> |
| In reply to | #127960 |
On 3/17/18 9:28 PM, bartc wrote: > On 17/03/2018 23:54, Richard Damon wrote: >> On 3/17/18 12:07 PM, bartc wrote: > >>> As well as abandoning support for one-file C sources, I've decided >>> for now to also drop support for generating any C source at all. > >>> * Generating code for a large project that is free of warnings is >>> difficult (and there will always be someone who will ramp it up >>> further). On some compilers, impossible. > >> One fundamental issues with your goals is that you seem to want your >> code to be warning free, for all implementations and all warning >> settings. This is fundamentally an impossibility. > > It doesn't seem impossible when I generate ASM code; the assembler is > generally very quiet unless something is clearly wrong (and then the > error is likely to be a compiler fault rather than application). > But at that point you need to generate different code for each family of processors. I thought that was one reason you had been using C as your output format, to try to get target independence in your output. > But C compilers have minds of their own and they will complain about > different things, even though IMO the code is correct, partly because it > has already been verified with my compiler. But I don't have full > confidence these days that the C compiler will do what I tell it. > But C compiler warnings aren't based on YOUR opinion of the code, but of the implementers opinion, and if you are going to try to make your code warning free to everyone you need to try to satisfy EVERYONE, which is, as I said, a fools errand. > Myself, I'm not too worried about most warnings, but people who have > tried to compile my generated C have complained about them. > The best solution for that is to document what implementations (and their options) you test with and work for zero warnings on, and include a disclaimer that many compilers will generate warnings for valid code, and while you have worked to minimize these, some warnings might occur. > (Note that my C compiler doesn't report warnings at all, only errors, > but perhaps it doesn't count > Some people will complain about not generating some warnings, so you can't even win by doing that.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-18 11:25 +0000 |
| Message-ID | <m0srC.13038$Il7.8205@fx46.am4> |
| In reply to | #127961 |
On 18/03/2018 01:41, Richard Damon wrote: > On 3/17/18 9:28 PM, bartc wrote: >> On 17/03/2018 23:54, Richard Damon wrote: >>> On 3/17/18 12:07 PM, bartc wrote: >> >>>> As well as abandoning support for one-file C sources, I've decided >>>> for now to also drop support for generating any C source at all. >> >>>> * Generating code for a large project that is free of warnings is >>>> difficult (and there will always be someone who will ramp it up >>>> further). On some compilers, impossible. >> >>> One fundamental issues with your goals is that you seem to want your >>> code to be warning free, for all implementations and all warning >>> settings. This is fundamentally an impossibility. >> >> It doesn't seem impossible when I generate ASM code; the assembler is >> generally very quiet unless something is clearly wrong (and then the >> error is likely to be a compiler fault rather than application). >> > > But at that point you need to generate different code for each family of > processors. I thought that was one reason you had been using C as your > output format, to try to get target independence in your output. Yes, that had been the idea. And it worked, as I could run programs on alien (to me) processors like ARM. But it came at some cost (like extra dependence in other areas, or losing features not expressible in C). For my own purposes, I am only only interested in a couple of extra processors (32-bit x86 and ARM32), so it would be easier (for x86 at least) just to add that support. That's not going to happen using C. Directly generating native code is 'better', and also more satisfying in that however well the code performs, it will be 100% due to my efforts rather than some optimising C compiler. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-18 04:33 -0700 |
| Message-ID | <f7fb5760-6368-4bc0-9f16-9705e42e7be1@googlegroups.com> |
| In reply to | #127968 |
On Sunday, March 18, 2018 at 4:25:22 AM UTC-7, Bart wrote: > On 18/03/2018 01:41, Richard Damon wrote: > > On 3/17/18 9:28 PM, bartc wrote: > >> On 17/03/2018 23:54, Richard Damon wrote: > >>> On 3/17/18 12:07 PM, bartc wrote: > >> > >>>> As well as abandoning support for one-file C sources, I've decided > >>>> for now to also drop support for generating any C source at all. > >> > >>>> * Generating code for a large project that is free of warnings is > >>>> difficult (and there will always be someone who will ramp it up > >>>> further). On some compilers, impossible. > >> > >>> One fundamental issues with your goals is that you seem to want your > >>> code to be warning free, for all implementations and all warning > >>> settings. This is fundamentally an impossibility. > >> > >> It doesn't seem impossible when I generate ASM code; the assembler is > >> generally very quiet unless something is clearly wrong (and then the > >> error is likely to be a compiler fault rather than application). > >> > > > > But at that point you need to generate different code for each family of > > processors. I thought that was one reason you had been using C as your > > output format, to try to get target independence in your output. > > Yes, that had been the idea. And it worked, as I could run programs on > alien (to me) processors like ARM. > > But it came at some cost (like extra dependence in other areas, or > losing features not expressible in C). > > For my own purposes, I am only only interested in a couple of extra > processors (32-bit x86 and ARM32), so it would be easier (for x86 at > least) just to add that support. That's not going to happen using C. > > Directly generating native code is 'better', and also more satisfying in > that however well the code performs, it will be 100% due to my efforts > rather than some optimising C compiler. > > -- > bartc Thanks to Autumn Elizabeth Nissen and his 'convenient friends' you now need an IP filtering system (which I made for Forté Agent and Opera Mail). If others start up with him again I will not be able to stop myself... as I promised. I'm referring to good people here, not idiots, who never do as we want anyway. Out-and-out poppycock by an uneducated, lying, slippery, collaborating idiot who could not be sincere even if he swore on his mother's grave. I have a Bash shell system I use as well, but it's something you would not understand. You guys can only understand from the perspective of a sociopath. Why does Autumn Elizabeth Nissen focus on Vennie Bowden, Realtor's pride so much? Just mindless trolling. And I am giving attention to that trolling. THAT is what the "Autumn Elizabeth Nissen circus" is. And you _do_ realize that it isn't impossible for Autumn Elizabeth Nissen to be doing this, or paying others to do so. -- This Trick Gets Women Hot For You! https://youtu.be/UkAyrfOZaXc https://youtu.be/48_DdtLGR9s https://www.youtube.com/playlist?list=PLU_evUKollmjeuJy5V5UMotPUs65Q7YM6 Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2018-03-19 00:05 +0100 |
| Message-ID | <p8mrbo$sih$1@dont-email.me> |
| In reply to | #127968 |
Le 18/03/2018 à 12:25, bartc a écrit : > Yes, that had been the idea. And it worked, as I could run programs on > alien (to me) processors like ARM. I couldn't do that. A C compiler must generate processor specific code. So, I learned ARM Asm. There is no other way actually. Nice machine, completely different than the x86. Another philosophy, very easy to grasp, regular, no surprises... To test my asm habilities, I rewrote the Cephes core in arm-64 asm. Funny. You have so many registers, that you can keep big quantities of data in them. For instance the core of the Cephes library multiplies a big deal to divide, since it has no division. Division is done by multiplying by the inverse. And the inverse is calculated without divisions, only subtraction and multiplication. And a shift. Newton iteration. Very fast. So, you can make a queue of 3 registers, cycling around results in loops. This avoids memory reads a lot. It was a nice construct. You can do 16 bit I/O with the load pair instruction, and it has even a 128 bit multiply. No 128 bit divide as the x86, and that was a big hit when porting the Cephes core to it... CISC has a 128 bit divide instruction, the RISC doesn't. I translated the virtual machine of lcc into arm assembly, figured out an assembler that I extracted from pieces of GNU gas, and then, at the end of assembly I thought that a nice touch would be to make a instantaneous compiler, that after compilation starts the executable on the spot. It allocates some RAM and jumps into it. All standard C functions are stored in a table of precompiled addresses, so you can use any C function within the program as a default. Or you can increase the table with your functions, whatever. This is a language tool. Want to write a new language? C doesn't cut it? Write your new language in C! So, Bart, you will have to learn ARM asm. Wellcome!
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-19 00:24 +0000 |
| Message-ID | <OqDrC.29588$sQ.26100@fx38.am4> |
| In reply to | #127976 |
On 18/03/2018 23:05, jacobnavia wrote: > Le 18/03/2018 à 12:25, bartc a écrit : >> Yes, that had been the idea. And it worked, as I could run programs on >> alien (to me) processors like ARM. > I translated the virtual machine of lcc into arm assembly, figured out > an assembler that I extracted from pieces of GNU gas, and then, at the > end of assembly I thought that a nice touch would be to make a > instantaneous compiler, that after compilation starts the executable on > the spot. > > It allocates some RAM and jumps into it. Yes, that's also what I was planning to do, but needed certain systems in place that I hadn't developed yet. > All standard C functions are stored in a table of precompiled addresses, > so you can use any C function within the program as a default. > > Or you can increase the table with your functions, whatever. > > This is a language tool. > > Want to write a new language? > > C doesn't cut it? Sorry, no. > Write your new language in C! And no to that too! Sorry but I've never found it comfortable nor productive writing C with its many annoyances that I've listed from time to time. I have an alternative, but for certain targets it has to go through a C compiler (not mine) which is grating. This is what I've stopped doing so that if I want code to run on ARM, I will have to target it directly. But it doesn't help that the two ARM systems I have are crappy machines that can't access the network files on my PC, so I have to transfer files (as the editors on those targets are unusable) via memory stick; or email. (I know about your Rock64 system.) > So, Bart, you will have to learn ARM asm. > > Wellcome! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-03-18 21:15 -0400 |
| Message-ID | <dbErC.23584$mV5.9134@fx02.iad> |
| In reply to | #127977 |
On 3/18/18 8:24 PM, bartc wrote: > On 18/03/2018 23:05, jacobnavia wrote: >> Le 18/03/2018 à 12:25, bartc a écrit : >>> Yes, that had been the idea. And it worked, as I could run programs >>> on alien (to me) processors like ARM. > >> I translated the virtual machine of lcc into arm assembly, figured out >> an assembler that I extracted from pieces of GNU gas, and then, at the >> end of assembly I thought that a nice touch would be to make a >> instantaneous compiler, that after compilation starts the executable >> on the spot. >> >> It allocates some RAM and jumps into it. > > Yes, that's also what I was planning to do, but needed certain systems > in place that I hadn't developed yet. > >> All standard C functions are stored in a table of precompiled >> addresses, so you can use any C function within the program as a default. >> >> Or you can increase the table with your functions, whatever. >> >> This is a language tool. >> >> Want to write a new language? >> >> C doesn't cut it? > > Sorry, no. > >> Write your new language in C! > > > And no to that too! Sorry but I've never found it comfortable nor > productive writing C with its many annoyances that I've listed from time > to time. > > I have an alternative, but for certain targets it has to go through a C > compiler (not mine) which is grating. This is what I've stopped doing so > that if I want code to run on ARM, I will have to target it directly. > > But it doesn't help that the two ARM systems I have are crappy machines > that can't access the network files on my PC, so I have to transfer > files (as the editors on those targets are unusable) via memory stick; > or email. > > (I know about your Rock64 system.) > >> So, Bart, you will have to learn ARM asm. >> >> Wellcome! > One thing to watch out with the ARM series is that there are two major distinct instruction sets that are part of ARM (and some other more minor variations). There is a 32 bit instruction set, which can access about 16 general purpose registers, and a 16 bit 'Thumb' instruction set which are much more limited in capabilities (and most of the instructions can only access 1/2 the registers). Some of the processors only support the Thumb set ((like the Cortex M series), and some support both (and calls can change which set is currently being used). The instruction sets are very similar in many respects, and generally the 16 bit instructions can be mapped into the 32 bit set, with certain fields just getting default values. Things like in the 32 bit instruction set, virtually all the instructions can be made conditional, while the Thumb set only branches are conditional. There are also some significant generational differences between the various generations of ARM processors.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-18 19:00 -0700 |
| Message-ID | <fe889908-c5ae-427d-86e1-415c4e10926f@googlegroups.com> |
| In reply to | #127979 |
On Sunday, March 18, 2018 at 6:16:01 PM UTC-7, Richard Damon wrote: > On 3/18/18 8:24 PM, bartc wrote: > > On 18/03/2018 23:05, jacobnavia wrote: > >> Le 18/03/2018 à 12:25, bartc a écrit : > >>> Yes, that had been the idea. And it worked, as I could run programs > >>> on alien (to me) processors like ARM. > > > >> I translated the virtual machine of lcc into arm assembly, figured out > >> an assembler that I extracted from pieces of GNU gas, and then, at the > >> end of assembly I thought that a nice touch would be to make a > >> instantaneous compiler, that after compilation starts the executable > >> on the spot. > >> > >> It allocates some RAM and jumps into it. > > > > Yes, that's also what I was planning to do, but needed certain systems > > in place that I hadn't developed yet. > > > >> All standard C functions are stored in a table of precompiled > >> addresses, so you can use any C function within the program as a default. > >> > >> Or you can increase the table with your functions, whatever. > >> > >> This is a language tool. > >> > >> Want to write a new language? > >> > >> C doesn't cut it? > > > > Sorry, no. > > > >> Write your new language in C! > > > > > > And no to that too! Sorry but I've never found it comfortable nor > > productive writing C with its many annoyances that I've listed from time > > to time. > > > > I have an alternative, but for certain targets it has to go through a C > > compiler (not mine) which is grating. This is what I've stopped doing so > > that if I want code to run on ARM, I will have to target it directly. > > > > But it doesn't help that the two ARM systems I have are crappy machines > > that can't access the network files on my PC, so I have to transfer > > files (as the editors on those targets are unusable) via memory stick; > > or email. > > > > (I know about your Rock64 system.) > > > >> So, Bart, you will have to learn ARM asm. > >> > >> Wellcome! > > > > One thing to watch out with the ARM series is that there are two major > distinct instruction sets that are part of ARM (and some other more > minor variations). There is a 32 bit instruction set, which can access > about 16 general purpose registers, and a 16 bit 'Thumb' instruction set > which are much more limited in capabilities (and most of the > instructions can only access 1/2 the registers). Some of the processors > only support the Thumb set ((like the Cortex M series), and some support > both (and calls can change which set is currently being used). > > The instruction sets are very similar in many respects, and generally > the 16 bit instructions can be mapped into the 32 bit set, with certain > fields just getting default values. Things like in the 32 bit > instruction set, virtually all the instructions can be made conditional, > while the Thumb set only branches are conditional. > > There are also some significant generational differences between the > various generations of ARM processors. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 - -- sex n 1. either of the two reproductive categories, male or female, of animals and plants 2. sexual intercourse 3. sexual activity or behavior leading to it 4. the genitals (literary) 5. the set of characteristics that determine whether the reproductive role of an animal or plant is male or female - -- And, notably, Snit wrote: "Sex is a subset of sexual activities" - Snit - (I guess he didn't comprehend point 3 very well) Of course, he also wrote: "Sexual activities are sex by definition, you moron" - Snit And this: "A passionate kiss could be called a "sexual activity" but it is not sex" In Snit's world, a passionate kiss is not sex... but it is sex. LOL! -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVRYvKAAoJEC03b6bOr/+dgbUP/icm7kQOjm2kSNou+JmBBgHb A4tmqQKGn3RwkS88wbmhuGrc7bj+Mn0olYmozNufRMG1hB+cjJR/a3K4qEN+hZP7 6KNdfvYKxSOcdtrsYEezCOPK6yu9tlwspR5w61vMaEWxmGX8CZ8FuZWnZhiul1CA WXRpPDK8GJnWecK7wqDw8wJCKu4ENRw0AUTFWdmmGIUO1n3x/NSbCXIftMop4MBd 9NHP3v26pA5NB9tlh//BtQa8Ys03DASuViFd1VRgtuL4wSnctDDLUE4zQGp+GcS7 DOhjROy9ExDGqer4uLwPwDD59eUef8s4WI/XRivl2uQSl7rs/XWKw4OStOzXajGX EMcJ4c9zPjtwKB2F781+U3DH2l9YLBii/UZCpgcblvvuXSb/b/7D64AxpzvEfPpZ TTq/OcOEDsbhaOijEdELMw/IjuQ+Pp+5cMEOey7BK3uPAjr8gOLU0xmChJimNP8r o9RzphsO8O+mJMK0sdke9FEJByCgX3LbJYro21v0ZS0Nt2JW16Z8VakHNKfUbuLg IYHbShHiEQ1GCWOQ+AIfpwG6td/NE/EhiCE9OixWAsvGq6e0w4k7vARG8hSfZDpp 3hp7rD8x9EVp4v4e7G34Wr6FIZlfYzD2fX6SRu9wYpG/v87sgvrN9klY1YLn/zig oZmOKJM5cC0iwnvHsavO =4yFU -----END PGP SIGNATURE----- -- Eight things to never feed your cat http://tinyurl.com/kmqe66h http://www.5z8.info/php-start_GPS_tracking-user_f8h9lv_-OPEN-WEBCAM---START-RECORD-- https://youtu.be/5OfWsoPAg7o Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-19 14:04 +0100 |
| Message-ID | <p8ochg$pb9$1@dont-email.me> |
| In reply to | #127979 |
On 19/03/18 02:15, Richard Damon wrote: > On 3/18/18 8:24 PM, bartc wrote: >> On 18/03/2018 23:05, jacobnavia wrote: >>> Le 18/03/2018 à 12:25, bartc a écrit : >>>> Yes, that had been the idea. And it worked, as I could run programs >>>> on alien (to me) processors like ARM. >> >>> I translated the virtual machine of lcc into arm assembly, figured >>> out an assembler that I extracted from pieces of GNU gas, and then, >>> at the end of assembly I thought that a nice touch would be to make a >>> instantaneous compiler, that after compilation starts the executable >>> on the spot. >>> >>> It allocates some RAM and jumps into it. >> >> Yes, that's also what I was planning to do, but needed certain systems >> in place that I hadn't developed yet. >> >>> All standard C functions are stored in a table of precompiled >>> addresses, so you can use any C function within the program as a >>> default. >>> >>> Or you can increase the table with your functions, whatever. >>> >>> This is a language tool. >>> >>> Want to write a new language? >>> >>> C doesn't cut it? >> >> Sorry, no. >> >>> Write your new language in C! >> >> >> And no to that too! Sorry but I've never found it comfortable nor >> productive writing C with its many annoyances that I've listed from >> time to time. >> >> I have an alternative, but for certain targets it has to go through a >> C compiler (not mine) which is grating. This is what I've stopped >> doing so that if I want code to run on ARM, I will have to target it >> directly. >> >> But it doesn't help that the two ARM systems I have are crappy >> machines that can't access the network files on my PC, so I have to >> transfer files (as the editors on those targets are unusable) via >> memory stick; or email. >> >> (I know about your Rock64 system.) >> >>> So, Bart, you will have to learn ARM asm. >>> >>> Wellcome! >> > > One thing to watch out with the ARM series is that there are two major > distinct instruction sets that are part of ARM (and some other more > minor variations). There is a 32 bit instruction set, which can access > about 16 general purpose registers, and a 16 bit 'Thumb' instruction set > which are much more limited in capabilities (and most of the > instructions can only access 1/2 the registers). Some of the processors > only support the Thumb set ((like the Cortex M series), and some support > both (and calls can change which set is currently being used). The original ARM Thumb, with 16-bit instructions and (mostly) access to only some of the registers, is effectively dead. Cortex M has Thumb-2 which has a mixture of 16-bit and 32-bit instructions and can make full use of all registers. The most common instructions will be 16-bit. The aim - which is mostly achieved - is code density matching that of Thumb and code speed matching 32-bit original ARM. Thumb-2 is not quite as orthogonal as ARM code - there is a fixed SP register, for example. And it does not have the conditional execution bits or the 3 register instructions. > > The instruction sets are very similar in many respects, and generally > the 16 bit instructions can be mapped into the 32 bit set, with certain > fields just getting default values. Things like in the 32 bit > instruction set, virtually all the instructions can be made conditional, > while the Thumb set only branches are conditional. > > There are also some significant generational differences between the > various generations of ARM processors. Indeed - though that applies to most ISA's. And of course there is the 64-bit ARM ISA too.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-19 06:08 -0700 |
| Message-ID | <6148ff26-67d0-4476-a617-1b7243c01e5b@googlegroups.com> |
| In reply to | #127994 |
On Monday, March 19, 2018 at 6:05:01 AM UTC-7, David Brown wrote:
> On 19/03/18 02:15, Richard Damon wrote:
> > On 3/18/18 8:24 PM, bartc wrote:
> >> On 18/03/2018 23:05, jacobnavia wrote:
> >>> Le 18/03/2018 à 12:25, bartc a écrit :
> >>>> Yes, that had been the idea. And it worked, as I could run programs
> >>>> on alien (to me) processors like ARM.
> >>
> >>> I translated the virtual machine of lcc into arm assembly, figured
> >>> out an assembler that I extracted from pieces of GNU gas, and then,
> >>> at the end of assembly I thought that a nice touch would be to make a
> >>> instantaneous compiler, that after compilation starts the executable
> >>> on the spot.
> >>>
> >>> It allocates some RAM and jumps into it.
> >>
> >> Yes, that's also what I was planning to do, but needed certain systems
> >> in place that I hadn't developed yet.
> >>
> >>> All standard C functions are stored in a table of precompiled
> >>> addresses, so you can use any C function within the program as a
> >>> default.
> >>>
> >>> Or you can increase the table with your functions, whatever.
> >>>
> >>> This is a language tool.
> >>>
> >>> Want to write a new language?
> >>>
> >>> C doesn't cut it?
> >>
> >> Sorry, no.
> >>
> >>> Write your new language in C!
> >>
> >>
> >> And no to that too! Sorry but I've never found it comfortable nor
> >> productive writing C with its many annoyances that I've listed from
> >> time to time.
> >>
> >> I have an alternative, but for certain targets it has to go through a
> >> C compiler (not mine) which is grating. This is what I've stopped
> >> doing so that if I want code to run on ARM, I will have to target it
> >> directly.
> >>
> >> But it doesn't help that the two ARM systems I have are crappy
> >> machines that can't access the network files on my PC, so I have to
> >> transfer files (as the editors on those targets are unusable) via
> >> memory stick; or email.
> >>
> >> (I know about your Rock64 system.)
> >>
> >>> So, Bart, you will have to learn ARM asm.
> >>>
> >>> Wellcome!
> >>
> >
> > One thing to watch out with the ARM series is that there are two major
> > distinct instruction sets that are part of ARM (and some other more
> > minor variations). There is a 32 bit instruction set, which can access
> > about 16 general purpose registers, and a 16 bit 'Thumb' instruction set
> > which are much more limited in capabilities (and most of the
> > instructions can only access 1/2 the registers). Some of the processors
> > only support the Thumb set ((like the Cortex M series), and some support
> > both (and calls can change which set is currently being used).
>
> The original ARM Thumb, with 16-bit instructions and (mostly) access to
> only some of the registers, is effectively dead. Cortex M has Thumb-2
> which has a mixture of 16-bit and 32-bit instructions and can make full
> use of all registers. The most common instructions will be 16-bit. The
> aim - which is mostly achieved - is code density matching that of Thumb
> and code speed matching 32-bit original ARM. Thumb-2 is not quite as
> orthogonal as ARM code - there is a fixed SP register, for example. And
> it does not have the conditional execution bits or the 3 register
> instructions.
>
> >
> > The instruction sets are very similar in many respects, and generally
> > the 16 bit instructions can be mapped into the 32 bit set, with certain
> > fields just getting default values. Things like in the 32 bit
> > instruction set, virtually all the instructions can be made conditional,
> > while the Thumb set only branches are conditional.
> >
> > There are also some significant generational differences between the
> > various generations of ARM processors.
>
> Indeed - though that applies to most ISA's.
>
> And of course there is the 64-bit ARM ISA too.
Steve "Steven Petruzzellis" Carroll's obsession with jacobnavia started in 2004 when Carroll got mad about his then girlfriend obsessing over jacobnavia (heavily documented here: <http://tinyurl.com/proof-about-ebot>). jacobnavia continued to respond to Steve for about 5 years, when Steve flipped out in 2009 and started contacting jacobnavia's employer with the stated goal to have him fired (he spoke of doing so even if he had to twist arms):
<http://goo.gl/OHNryA>
<http://goo.gl/MZ6yCD>
<http://goo.gl/WaKKGq>
There were more, but Carroll has had them deleted from the Google archive. I have not spent the time to find them elsewhere (and likely will not).
With that jacobnavia stopped responding directly to Steve except for *one* chance he gave him in 2011 when Steve was accusing *jacobnavia* of running: <http://goo.gl/racU64>.
Carroll, as predicted, ran (he always does when faced with facts):
<http://goo.gl/qHs5Xh>
Steven Petruzzellis knows he has no backing for any of his nonsense and has become, if anything, more and more obsessive since jacobnavia stopped responding to him.
Steve "Steven Petruzzellis" Carroll is truly a very, very sick man.
--
Do not click this link!
http://www.5z8.info/dogs-being-eaten_g0w7hf_molotovcocktail
http://www.5z8.info/facebook-of-sex_w4l4wg_bomb
https://groups.google.com/forum/#!topic/comp.os.linux.development.apps/G2-ZXYAEyIM
Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-19 14:29 -0700 |
| Message-ID | <9f5d167f-2a27-40b0-bccb-870276a3cc82@googlegroups.com> |
| In reply to | #127994 |
On Monday, March 19, 2018 at 8:05:01 AM UTC-5, David Brown wrote: > The original ARM Thumb, with 16-bit instructions and (mostly) access to > only some of the registers, is effectively dead. Cortex M has Thumb-2 > which has a mixture of 16-bit and 32-bit instructions and can make full > use of all registers. The most common instructions will be 16-bit. The > aim - which is mostly achieved - is code density matching that of Thumb > and code speed matching 32-bit original ARM. Thumb-2 is not quite as > orthogonal as ARM code - there is a fixed SP register, for example. And > it does not have the conditional execution bits or the 3 register > instructions. Cortex-M3 behaves as you describe. Many inexpensive low-power controllers, however, use Cortex-M0 which adds very few instructions compared with the original Thumb. While Cortex-M3 has a two-half-word instruction format that supports most 32-bit instructions with the exception of some load/store addressing modes or conditional instructions, and adds an "if-then" instruction which can make up to four succeeding instructions execute conditionally, Cortex-M0 includes neither of those things.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2018-03-19 14:34 +0100 |
| Message-ID | <p8oe8t$6fa$1@dont-email.me> |
| In reply to | #127977 |
On 19/03/2018 01:24, bartc wrote: > Sorry but I've never found it comfortable nor productive writing C > with its many annoyances that I've listed from time to time. It makes no sense to me that you spend so much time criticizing C in a C newsgroup. What do you hope to achieve? It's fine for you to enjoy other languages. Why are you trying to convince us that C sucks?
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-19 06:39 -0700 |
| Message-ID | <65984b27-db74-4d03-ad0e-1644fb5077a7@googlegroups.com> |
| In reply to | #127996 |
On Monday, March 19, 2018 at 6:34:31 AM UTC-7, Noob wrote: > On 19/03/2018 01:24, bartc wrote: > > > Sorry but I've never found it comfortable nor productive writing C > > with its many annoyances that I've listed from time to time. > > It makes no sense to me that you spend so much time criticizing C > in a C newsgroup. What do you hope to achieve? > > It's fine for you to enjoy other languages. Why are you trying > to convince us that C sucks? The complete sham is brimming of ridiculous inconsistencies and leans heavily on Autumn Elizabeth Nissen's 'vitamin D' shenanigans. It was Autumn Elizabeth Nissen who was publicly asking how better to hide his forgeries. Vennie Bowden, Real Estate Agent and I will intoxicate Autumn Elizabeth Nissen with my brain. You do, of course realize that the massive floods ending up in multiple groups started out as a joke about hacking Google. Why the added task to view data via ODBC connectivity in a mobile system? Whatever, Autumn Elizabeth Nissen didn't state this as part of his, predictably, self-serving 'needs' <whatever>. Oh goodness, that is just tons of rot. It was Autumn Elizabeth Nissen who forged me and did not even try to hide it. -- Top 15 Ways Autumn Elizabeth Nissen Trolls! https://groups.google.com/forum/#!topic/alt.os.linux/BVpdH5KOc6s Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2018-03-19 15:17 +0100 |
| Message-ID | <20180319151705.b62a6689c1344c41f2bf73ad@gmail.com> |
| In reply to | #127996 |
On Mon, 19 Mar 2018 14:34:20 +0100 Noob <root@127.0.0.1> wrote: > It makes no sense to me that you spend so much time criticizing C > in a C newsgroup. What do you hope to achieve? > > It's fine for you to enjoy other languages. Why are you trying > to convince us that C sucks? It seems he needs to convince himself that his programming language is better than C despite many said it isn't. :-) -- GOTHIER Nathan
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-19 15:03 +0000 |
| Message-ID | <qjQrC.15733$3o5.5088@fx20.am4> |
| In reply to | #127999 |
On 19/03/2018 14:17, GOTHIER Nathan wrote:
> On Mon, 19 Mar 2018 14:34:20 +0100
> Noob <root@127.0.0.1> wrote:
>
>> It makes no sense to me that you spend so much time criticizing C
>> in a C newsgroup. What do you hope to achieve?
>>
>> It's fine for you to enjoy other languages. Why are you trying
>> to convince us that C sucks?
>
> It seems he needs to convince himself that his programming language is
> better than C despite many said it isn't. :-)
Quite the opposite; I've been trying to convince myself since 1992 that
the very famous 'C' language I'd heard so much about was better that my
home-made efforts.
But even if it actually is, then it's clearly not for me. Here's a piece
of code posted in another group the other day:
[On 18/03/2018 10:39, Pascal J. Bourguignon wrote:]
--------------------------------
#include <stdio.h>
int main(int argc,char* argv[]){
const char* sep="";
for(int i=1;i<argc;i++){
printf("%s%s",sep,argv[i]);
sep=" ";}
printf("\n");
fflush(stdout);
return 0;}
--------------------------------
And here's how I'd write the same thing
--------------------------------
import main
proc start =
int i
for i to nsysparams do
print sysparams[i]
if i<nsysparams then print " " fi
od
println
end
--------------------------------
The C version has 51 punctuation characters. Mine has six.
Combined with mysterious macro calls all over the place (those
upper-case names lurking in various odd places that don't seem to fit
into the syntax), macro calls disguised as functions, consts littered
everywhere, upper and lower case mixed willy-nilly, loads and loads of
parentheses, #if/#ifdef blocks, #includes hidden halfway down a file,
all those __attribute__((whatever))...
Everything about it is a visual disaster. Sorry.
Even though what it does, and what I want to do, correspond.
Have a look at my recent post in Future of C about asm syntax - even
there, what ought to be straightforward assembly is so uglified that it
is nearly unreadable.
What is it about this mindset that likes this really ugly, untidy,
unconstrained code?
---------------------
BTW I've been meaning to ask this for a while: given an ordinary text
editor, and given the name of a function, how do you find that function
definition in a source file? I mean, going straight there rather then
scanning a hundred other occurrences of the name before you get to the
definition.
--
bartc
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web