Author Topic: Design a better "C"  (Read 31968 times)

0 Members and 2 Guests are viewing this topic.

Offline gf

  • Super Contributor
  • ***
  • Posts: 1114
  • Country: de
Re: Design a better "C"
« Reply #100 on: July 25, 2021, 06:10:01 pm »
That is incorrect. As I already stated above, a string literal in C has type `char [N]`.

Sorry, typo. the type of a string literal is of course an array, not a pointer.
But you are right, in C it is not const (I mixed up with C++, here it is const).
https://en.cppreference.com/w/c/language/string_literal
Then I'm indeed wondering why the compiler places the string literal in .rodata?
 

Online SiliconWizardTopic starter

  • Super Contributor
  • ***
  • Posts: 14230
  • Country: fr
Re: Design a better "C"
« Reply #101 on: July 25, 2021, 06:16:13 pm »
That is incorrect. As I already stated above, a string literal in C has type `char [N]`.

Sorry, typo. the type of a string literal is of course an array, not a pointer.
But you are right, in C it is not const (I mixed up with C++, here it is const).
https://en.cppreference.com/w/c/language/string_literal
Then I'm indeed wondering why the compiler places the string literal in .rodata?

Well well well...
Thanks to the infamous UB. The standard says: "If the  program  attempts  to  modify  such  an  array, the  behavior  is undefined."
Since modifying arrays formed by string literals is UB, compilers are free to assume they are read-only. So, this is what most compilers do. But, since they are not 'const', the read-only characteristic is not enforced at the source level. So, no warning. (Except again with decent static analyzers.) This makes perfect sense, but it's not particularly pretty.


« Last Edit: July 25, 2021, 06:19:03 pm by SiliconWizard »
 

Offline gf

  • Super Contributor
  • ***
  • Posts: 1114
  • Country: de
Re: Design a better "C"
« Reply #102 on: July 25, 2021, 08:26:27 pm »
IMO the C++ definition, where the type of string literals is const char[], makes more sense, when attempts to modify the array are UB anyway.

Edit: I wonder whether the non-const string literals are still a leftover from K&R C, which did not yet have "const"?
« Last Edit: July 25, 2021, 08:35:31 pm by gf »
 

Offline TheCalligrapher

  • Regular Contributor
  • *
  • Posts: 151
  • Country: us
Re: Design a better "C"
« Reply #103 on: July 25, 2021, 10:12:48 pm »
Then I'm indeed wondering why the compiler places the string literal in .rodata?

Even though the type of string literal is not `const`, the literal is still officially non-modifiable and therefore can be placed into the read-only data segment.

The type is not `const` just for compatibility with legacy versions of the language.

C++ also maintained this compatibility (with C) in the first version of C++ standard: even though in C++ string literals are `const` arrays, in C++98 they were still implicitly convertible to `char *` pointers. This unusual conversion was deprecated from day one. It has been discarded from the language in C++11.
« Last Edit: July 26, 2021, 12:36:30 am by TheCalligrapher »
 

Online SiliconWizardTopic starter

  • Super Contributor
  • ***
  • Posts: 14230
  • Country: fr
Re: Design a better "C"
« Reply #104 on: July 27, 2021, 04:51:19 pm »
C is obviously lacking anything regarding this, but that's part of what many people think it's seriously limited. So if you're one of those people, you would have to consider this for any potential language replacement.

If you need a practical target of reference, look at the Epiphany-V, for instance the version with 1024-cores.
Programming it in C has already demonstrated to be limited and very prone to catastrophic results  :D

What's the typical language used for programming this then?
 

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3772
  • Country: gb
Re: Design a better "C"
« Reply #105 on: July 27, 2021, 07:10:24 pm »
C is obviously lacking anything regarding this, but that's part of what many people think it's seriously limited. So if you're one of those people, you would have to consider this for any potential language replacement.

If you need a practical target of reference, look at the Epiphany-V, for instance the version with 1024-cores.
Programming it in C has already demonstrated to be limited and very prone to catastrophic results  :D

What's the typical language used for programming this then?

precisely the two main questions it leads to:
  • Which is the best parallel programming language for initiating undergraduate students in the world of parallel computing?
  • OpenCL can be used in a variety of multicore systems and growing, but is it a good candidate?

I don't know  :-//

I program my Epiphany-V cores in eRlang, but I have heard some guys having good results with "C=", aka "C Stripes", a C-like but Parallel Programming Language designed with a couple of extensions on the top of the traditional "C language" to cover all typical parallel programming paradigms and complement or even substitute existing parallel language extensions and libraries by providing a single parallel language most naturally connected with the C-like syntax and semantics.
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: Design a better "C"
« Reply #106 on: July 27, 2021, 07:18:37 pm »
I'm quite happy to look at other languages. An example: Swift on macOS. it's a pretty neat language. (A lot is hidden in the run-time ... kinda like Ada, huh?) I thought Objective-C with its message-passing idiom was pretty neat. Rust looks interesting. And like most people reading this, I dabble in Python for quick test code and whatever.

But for actual work, which for me is embedded microcontrollers and FPGAs, I'm wholly uninterested in new languages. Wake me when, for example, a vendor has a full-up Rust environment that works as well as the C stuff they provide. That is: libraries, debuggers, example code, the whole of it.

And for FPGAs, whatever new languages someone might be creating are useless until Xilinx, Intel/Altera and Synopsys have full-up synthesis support and Xilinx and ModelSim have full-up simulation/verification support. None of this generating-intermediate-Verilog stuff.

 

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3772
  • Country: gb
Re: Design a better "C"
« Reply #107 on: July 27, 2021, 07:33:51 pm »
FPGAs

FPGAs don't need anything else, just VHDL and Verilog (perhaps also SCALA, which outputs VHDL and Verilog)
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 3971
  • Country: nz
Re: Design a better "C"
« Reply #108 on: July 28, 2021, 01:06:53 am »
I'm quite happy to look at other languages. An example: Swift on macOS. it's a pretty neat language.

Swift is pretty cool. It's also open source and available on all the major desktop OSes --- for example swift.ord has pre-packaged toolchains for Swift 5.4.2 dated June 28 2021 for MacOS, Ubuntu 16.04, 18.04, 20.04, CentOS 7 & 8, Amazon Linux 2, Windows 10.

Quote
But for actual work, which for me is embedded microcontrollers and FPGAs, I'm wholly uninterested in new languages. Wake me when, for example, a vendor has a full-up Rust environment that works as well as the C stuff they provide. That is: libraries, debuggers, example code, the whole of it.

I'm similar. For small systems I'm really only interested in C and assembler. And only in ISAs that have gcc and/or llvm support.

I could stretch that to other languages that use gcc or llvm optimiser and back end, and don't need a significant runtime library.

Quote
And for FPGAs, whatever new languages someone might be creating are useless until Xilinx, Intel/Altera and Synopsys have full-up synthesis support and Xilinx and ModelSim have full-up simulation/verification support. None of this generating-intermediate-Verilog stuff.

I have to disagree there. It's the moral equivalent of a higher level language compiling to portable C. That's a perfectly fine strategy and I've used many of them (and written a couple).
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 3971
  • Country: nz
Re: Design a better "C"
« Reply #109 on: July 28, 2021, 01:12:10 am »
FPGAs

FPGAs don't need anything else, just VHDL and Verilog (perhaps also SCALA, which outputs VHDL and Verilog)

Scala doesn't output VHDL and Verilog.

Certain *libraries* written in Scala output VHDL and Verilog. In fact Chisel outputs FIRRTL, which is similar to LLVM IR, and also can go through a variety of optimisation passes before eventually being converted to VHDL or Verilog.

Also, MyHDL and PyHDL (maybe others too) use Python in the same manner as Chisel and SpinalHDL use Scala.
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: Design a better "C"
« Reply #110 on: July 28, 2021, 07:04:22 am »
FPGAs

FPGAs don't need anything else, just VHDL and Verilog (perhaps also SCALA, which outputs VHDL and Verilog)

They don't, but that doesn't stop people from trying to come up with something "better."
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23017
  • Country: gb
Re: Design a better "C"
« Reply #111 on: July 28, 2021, 07:18:42 am »
FPGAs

FPGAs don't need anything else, just VHDL and Verilog (perhaps also SCALA, which outputs VHDL and Verilog)

Scala doesn't output VHDL and Verilog.

Certain *libraries* written in Scala output VHDL and Verilog. In fact Chisel outputs FIRRTL, which is similar to LLVM IR, and also can go through a variety of optimisation passes before eventually being converted to VHDL or Verilog.

Also, MyHDL and PyHDL (maybe others too) use Python in the same manner as Chisel and SpinalHDL use Scala.

Just to add on that, we bought out a company that wrote half their stuff in Scala. We are currently rewriting their product in "not Scala" and they have tears of joy because it was their number one mistake apparently.



Interestingly yesterday I had to MacGyver some shit up extremely quickly to replace an infrastructure component (from Microsoft) which failed under load testing. Now usually I'd probably attack this problem in C as it's suited to the application here which is roughly suck up UDP packets, parse and relay to stdout. But I needed some protection against back pressure which is quite difficult with C. You end up either having to do everything with select which is a pain in the butt. Add to that the fact I didn't have time available to make any memory management mistakes and needed portability between Windows and didn't want to write it on Windows to start with because that's just painful, I picked Go.

I had the job done in 90 lines and 90 minutes. Hosted on macOS/arm64 with binary outputs generated for Linux/amd64 and Windows/amd64. Target nodes sinking 350,000 UDP packets a minute at 3% CPU passing sustained load test.

That is now a better "C". They reduced time to market, ability to shoot your toes off and made cross compilation a joy.
« Last Edit: July 28, 2021, 07:28:08 am by bd139 »
 

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3772
  • Country: gb
Re: Design a better "C"
« Reply #112 on: July 28, 2021, 10:00:51 am »
They don't, but that doesn't stop people from trying to come up with something "better."

and me to ignore them  :D
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Online SiliconWizardTopic starter

  • Super Contributor
  • ***
  • Posts: 14230
  • Country: fr
Re: Design a better "C"
« Reply #113 on: July 28, 2021, 04:15:17 pm »
FPGAs

FPGAs don't need anything else, just VHDL and Verilog (perhaps also SCALA, which outputs VHDL and Verilog)

They don't, but that doesn't stop people from trying to come up with something "better."

While I myself said that I wouldn't use one of those "higher-level" HDLs and would stick to the standard ones for a number of reasons, I'll still honestly admit that it has proven to work in some cases. SiFive has been successful using Chisel and I don't think they have a plan to switch back to Verilog or VHDL any time soon. (Now if Intel does acquire SiFive as was being discussed, things may change, but also as we discussed, Intel's main reason for buying SiFive if they ever do may not be directly reusing their cores anyway...)

 

Online SiliconWizardTopic starter

  • Super Contributor
  • ***
  • Posts: 14230
  • Country: fr
Re: Design a better "C"
« Reply #114 on: July 28, 2021, 10:40:32 pm »
So... this one is fun:
https://sysdig.com/blog/cve-2021-33909-sequoia-falco-linux-filesystem/

Note that enabling proper warnings/using static analysis on this (and of course caring about LOOKING and fixing the issue) would have avoided the bug.
The f*cking -Wconversion flag should be enabled by default when using -Wall in GCC. Really. I have already talked about how I always enable it.

I have actually never issued static analysis on the Linux kernel source code (never contributed either), but I'd be curious to do just that.
 

Offline DiTBho

  • Super Contributor
  • ***
  • Posts: 3772
  • Country: gb
Re: Design a better "C"
« Reply #115 on: July 28, 2021, 11:27:14 pm »
Probably scheduled for kernel v6 or v7. At the moment I see a lot of code regressions, which means that old friends of bugs that should have already been defeated go back to saying "hAllo again".

Any comment about "C="?
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Online SiliconWizardTopic starter

  • Super Contributor
  • ***
  • Posts: 14230
  • Country: fr
Re: Design a better "C"
« Reply #116 on: July 28, 2021, 11:43:09 pm »
Any comment about "C="?

I took a quick look and didn't see anything particularly interesting in that, I mean compared to alternatives. Is there a compiler for this?

I had looked at Cilk, years ago. https://en.wikipedia.org/wiki/Cilk
Cilk influenced OpenMP, and GCC has been supporting OpenMP for many versions now, so I think OpenMP would be the more standard alternative. I've used it only a little bit so far. "C=" may just look like it has a bit better syntax sugar coating, but otherwise, the same functionalities are there in OpenMP. Don't hesitate to tell me what C= would do better (again apart from syntax), as you may be more familiar with it than I am.
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: Design a better "C"
« Reply #117 on: July 29, 2021, 05:49:20 pm »
FPGAs

FPGAs don't need anything else, just VHDL and Verilog (perhaps also SCALA, which outputs VHDL and Verilog)

They don't, but that doesn't stop people from trying to come up with something "better."

While I myself said that I wouldn't use one of those "higher-level" HDLs and would stick to the standard ones for a number of reasons, I'll still honestly admit that it has proven to work in some cases. SiFive has been successful using Chisel and I don't think they have a plan to switch back to Verilog or VHDL any time soon. (Now if Intel does acquire SiFive as was being discussed, things may change, but also as we discussed, Intel's main reason for buying SiFive if they ever do may not be directly reusing their cores anyway...)

I started here. I found and spent some time reading through The Chisel Book and ... I don't see where Chisel is better than VHDL or SystemVerilog. Honestly. The syntax is different. The book also has an odd statement:

Quote
10 Hardware Generators
The strength of Chisel is that it allows us to write so-called hardware generators. With older hardware description languages, such as VHDL and Verilog, we usually use another language, e.g., Java or Python, to generate hardware. The author has often written small Java programs to generate VHDL tables.

"Generate hardware" must mean "generate a table that gets synthesized into a ROM." Because other than that, I've never written a Python script to generate hardware!  I honestly don't know what is meant by that statement.

The main Chisel page has a link to a Stack Exchange article full of sound and fury, but signifying nothing, as it doesn't actually answer the question posed.

One of the things that seems weird to me is that it has a notion of an implicit clock for registers. Many FPGA designs have multiple clocks, and it is really handy to know which clock is driving which elements! And it would be interesting to see an example of how to manage clock-domain crossings in Chisel.

I don't see how Chisel allows for instantiation of black boxes for FPGA features like deserializers and other I/O things, clock management blocks and the like. Perhaps someone has written libraries which present those features as modules you instantiate, and there's some magic under the hood that manages this?

Does Chisel support parametrized design and generics and the like? Can I instantiate multiple copies of a lower-level entity like I can in VHDL with a generate loop? I have some designs here which has a "channel" entity which can be replicated simply with such a loop.

I'd like to see an example of a small but complete hierarchical FPGA design written in Chisel. The design should include lower-level entities/modules/whatever as instantiated in the top level. Some of those lower-level things should themselves instantiate even lower level things.

Anyway. I'm honestly open to learning about why Chisel/Scala could be better. But for my designs, which tend to be kitchen-sink collections of stuff with a bunch of external peripherals which need servicing, I don't see the advantages.
 
The following users thanked this post: DiTBho, Just_another_Dave

Offline madires

  • Super Contributor
  • ***
  • Posts: 7673
  • Country: de
  • A qualified hobbyist ;)
Re: Design a better "C"
« Reply #118 on: July 29, 2021, 06:19:53 pm »
This discussion reminds me of a classic xkcd: https://m.xkcd.com/927/ ;D
 
The following users thanked this post: cfbsoftware

Offline Just_another_Dave

  • Regular Contributor
  • *
  • Posts: 192
  • Country: es
Re: Design a better "C"
« Reply #119 on: July 29, 2021, 09:00:19 pm »
FPGAs

FPGAs don't need anything else, just VHDL and Verilog (perhaps also SCALA, which outputs VHDL and Verilog)

They don't, but that doesn't stop people from trying to come up with something "better."

While I myself said that I wouldn't use one of those "higher-level" HDLs and would stick to the standard ones for a number of reasons, I'll still honestly admit that it has proven to work in some cases. SiFive has been successful using Chisel and I don't think they have a plan to switch back to Verilog or VHDL any time soon. (Now if Intel does acquire SiFive as was being discussed, things may change, but also as we discussed, Intel's main reason for buying SiFive if they ever do may not be directly reusing their cores anyway...)

I started here. I found and spent some time reading through The Chisel Book and ... I don't see where Chisel is better than VHDL or SystemVerilog. Honestly. The syntax is different. The book also has an odd statement:

Quote
10 Hardware Generators
The strength of Chisel is that it allows us to write so-called hardware generators. With older hardware description languages, such as VHDL and Verilog, we usually use another language, e.g., Java or Python, to generate hardware. The author has often written small Java programs to generate VHDL tables.

"Generate hardware" must mean "generate a table that gets synthesized into a ROM." Because other than that, I've never written a Python script to generate hardware!  I honestly don't know what is meant by that statement.

The main Chisel page has a link to a Stack Exchange article full of sound and fury, but signifying nothing, as it doesn't actually answer the question posed.

One of the things that seems weird to me is that it has a notion of an implicit clock for registers. Many FPGA designs have multiple clocks, and it is really handy to know which clock is driving which elements! And it would be interesting to see an example of how to manage clock-domain crossings in Chisel.

I don't see how Chisel allows for instantiation of black boxes for FPGA features like deserializers and other I/O things, clock management blocks and the like. Perhaps someone has written libraries which present those features as modules you instantiate, and there's some magic under the hood that manages this?

Does Chisel support parametrized design and generics and the like? Can I instantiate multiple copies of a lower-level entity like I can in VHDL with a generate loop? I have some designs here which has a "channel" entity which can be replicated simply with such a loop.

I'd like to see an example of a small but complete hierarchical FPGA design written in Chisel. The design should include lower-level entities/modules/whatever as instantiated in the top level. Some of those lower-level things should themselves instantiate even lower level things.

Anyway. I'm honestly open to learning about why Chisel/Scala could be better. But for my designs, which tend to be kitchen-sink collections of stuff with a bunch of external peripherals which need servicing, I don't see the advantages.

Although I haven’t found an official procedure for sending comments to the vhdl standard committee as the one that exists in the case of ada (http://www.ada-auth.org/comment.html), it seems that they use a wiki and a git lab repo for that purpose (http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/WebHome). Therefore, if being able to use hardware-generators (instructions for generating specification tables from a higher level language) was the only reason for creating Chisel, sending a feature request to the committee might have been easier than implementing a whole new language

Don’t get me wrong, I’m not saying that Chisel is a bad thing. It’s just that adding new features to an existing language seems to require less work
 
The following users thanked this post: Bassman59, DiTBho

Offline SL4P

  • Super Contributor
  • ***
  • Posts: 2318
  • Country: au
  • There's more value if you figure it out yourself!
Re: Design a better "C"
« Reply #120 on: July 30, 2021, 12:53:13 am »
Having scrolled through this thread, it confirms my own thoughts and beliefs…
I started with C about 30 years ago, and glad I’m still using it.

There’s enough capability in C to do almost anything, especially on low spec hardware.
I’ve written one small Python project for a friend, and know that the ‘benefits’ are nowhere the waste of time.
I dropped interpreted languages with BASIC.
Don't ask a question if you aren't willing to listen to the answer.
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23017
  • Country: gb
Re: Design a better "C"
« Reply #121 on: July 30, 2021, 08:00:56 am »
Your comment doesn’t scale well. The moment you need more complex data structures, parsing or network communications you’ll still be fixing bugs in yours while the python guys have finished their project and are sipping cocktails on the beach.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8089
  • Country: fi
Re: Design a better "C"
« Reply #122 on: July 30, 2021, 08:29:07 am »
python guys have finished their project and are sipping cocktails on the beach.

... because someone wrote the implementation in C, and the "Python guys" instantiated that.
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23017
  • Country: gb
Re: Design a better "C"
« Reply #123 on: July 30, 2021, 09:14:58 am »
Correct.

Python is just a quick way to glue bits of C together  :-DD
 
The following users thanked this post: Siwastaja, newbrain, DiTBho

Online SiliconWizardTopic starter

  • Super Contributor
  • ***
  • Posts: 14230
  • Country: fr
Re: Design a better "C"
« Reply #124 on: July 30, 2021, 05:12:24 pm »
Would be nice if the thread could get back on track, though.
HDLs, Python...?
Next thing you know, people are going to start talking about Javascript. Yeah, no.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf