August 07, 2003 Re: Project feedback - debugger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Frank Wills | Frank Wills <fdwills@sandarh.com> wrote in news:bgsahk$21bb$1@digitaldaemon.com: > I'd _like_ to have a fully supportive debugger if I'm writing a debugger. Otherwise it would be too much work and go too slow. That's what got me thinking about falling back on using C++ as a bootstrap project for a D version. Of course I would enjoy coding D more than C++. Why not ask Walter to further extend the amount of generated debug data? AFAIK, DMD generates line numbers and typeinfo for local or global variables. But it doesn't generate debug info for struct or class members and it uses the inappropriate type '__int64' for D arrays. I think, if DMD would generate debug info for structs and classes as DMC++ already does, debugging of D code would be *much* easier. Furthermore D arrays should not be tagged as type __int64, but as a C struct that represents the implementation of D arrays, like typedef struct { unsigned int length; void* ptr; } DArray; secondary topic: > I was disappointed that MS went the route of using a VM. [...] But it seems that some clever people at MS left the door open to native compilation, as the "kernel profile" for C# does not require any advanced reflection support. But I haven't heard of a native compiler with a native runtime for C#, yet. |
August 07, 2003 OT: JIT, VM, Sound, WTC. Re: Project feedback - debugger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Frank Wills | Frank Wills wrote: > Couldn't that kind of optimization be done without any kind of > VM? Just do the optimization when the code loads, but don't > add any kind of VM layer? It could, if you would exactly know what data is constant and what not, by patching. Even better, since you can profit from a powerful optimiser. However, if you take generic matrix multi > That's pretty interesting. I found this article on Structural Audio > related to the twin towers in NY. > http://www.cyberclass.net/palmquist.htm This is different. It's about de*struct*ion, as well as *struct*ure engeneering vs. *audio* engeneering. Besides, for such non-monolythic things (unlike planes and bridges), frequencies are probably too low. And yet another thing: they were build to hold wind and impact. And wind can be *really* hard through turbulences, and thus caused very poweful vibrations, which for some distinct wind speed may fall together with a resonation freqency. And yet, they couldn't collapse if the metal didn't melt. Not that i was an expert, but there are too many factors, be it economic, political, jurisdictional, and so on, that i could think they collapsed by accident. It can be proven that buildings were not hit by the boeing-sozed planes. The hole was simply too small: it was as large as from a 1-man plane which hit Pirelli center in Italy a few weeks before. See more here: http://www.serendipity.li/wot/psyopnews1.htm http://www.serendipity.li/wot/wtc_ch2.htm http://www.serendipity.li/wtc.htm and ascending. This is not at all original, i found a similar analysis a few monts after the fall on a german website dedicated to Mahatma Gandhi. --- Structural Audio is a composition of all information to create a sound by its source pieces. In a real world, you can decribe a sound by packing a musical score, a few instruments, and musicials which play them with their special style, in a huge box, and make them play on demand. :) In a computer world things are much easier. Since music is recorded using computers anyway, it is initally composed of a MIDI score, live wave recordings like vocals, and synthesis algorithms and data. By utilising this information available at creation, one can achieve high compression ratios compared to streaming formats like MP3 and OGG. Simplest examples of structural audio include MOD-like data formats, which contain a score and instrument wave data, but a simple pack of MIDI and a soundbank would also qualify. However, there's more to it. "Real" structural audio formats, like CSound and MPEG4-SA, allow for > Yes, .NETs VM is in my opinion a much better thing than what > Java VMs tend to be. I wonder if .NET isn't more in the direction > of what you are talking about. Not really. But since any VM supports reflection, any would theoretically do. Besides, most .NET VM always compile and never interpret - it doesn't take much more time to compile without any optimisations. MONO compiler shall be 2-stage: as soon as the function is called often enough, it is compiled with full optimisation. After a short while, source/bytecode need not be held in memory any longer - either because a function is used rarely and need not be optimised, or because it's optimised to 100%. This compile-only behaviour is fortunate for any use with repetitious code, especially if full optimisation can be assumed at once. -i. |
August 07, 2003 Re: Project feedback - debugger: Walter - extend debug data? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Farmer | Farmer wrote: > Frank Wills <fdwills@sandarh.com> wrote in news:bgsahk$21bb$1@digitaldaemon.com: > > >>I'd _like_ to have a fully supportive debugger if I'm writing a >>debugger. Otherwise it would be too much work and go too slow. That's >>what got me thinking about falling back on using C++ as a bootstrap >>project for a D version. Of course I would enjoy coding D more than >>C++. > > > Why not ask Walter to further extend the amount of generated debug data? > > AFAIK, DMD generates line numbers and typeinfo for local or global variables. > But it doesn't generate debug info for struct or class members and it uses the inappropriate type '__int64' for D arrays. > > I think, if DMD would generate debug info for structs and classes as DMC++ already does, debugging of D code would be *much* easier. > Furthermore D arrays should not be tagged as type __int64, but as a C struct that represents the implementation of D arrays, like > typedef struct { > unsigned int length; > void* ptr; > } DArray; > That explains what I've been seeing when I debug an app in Visual Studio. Char arrays show up as a large int value. Walter, is this something you could do? What is the current state of debug info? > > > secondary topic: > >>I was disappointed that MS went the route of using a VM. [...] > > But it seems that some clever people at MS left the door open to native compilation, as the "kernel profile" for C# does not require any advanced reflection support. But I haven't heard of a native compiler with a native runtime for C#, yet. There is a compiler that comes with the SDK. I've used it but not looked at it more than to see if there was any difference in load and execution speed. |
August 08, 2003 Re: OT: JIT, VM, Sound, WTC. Re: Project feedback - debugger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ilya Minkov | This is some pretty interesting reading, including the links. Ilya Minkov wrote: > Frank Wills wrote: > >> Couldn't that kind of optimization be done without any kind of >> VM? Just do the optimization when the code loads, but don't >> add any kind of VM layer? > > > It could, if you would exactly know what data is constant and what not, by patching. Even better, since you can profit from a powerful optimiser. However, if you take generic matrix multi This sentence got cut off. > >> That's pretty interesting. I found this article on Structural Audio >> related to the twin towers in NY. >> http://www.cyberclass.net/palmquist.htm > > > This is different. It's about de*struct*ion, as well as *struct*ure engeneering vs. *audio* engeneering. Besides, for such non-monolythic things (unlike planes and bridges), frequencies are probably too low. And yet another thing: they were build to hold wind and impact. And wind can be *really* hard through turbulences, and thus caused very poweful vibrations, which for some distinct wind speed may fall together with a resonation freqency. And yet, they couldn't collapse if the metal didn't melt. Not that i was an expert, but there are too many factors, be it economic, political, jurisdictional, and so on, that i could think they collapsed by accident. > > It can be proven that buildings were not hit by the boeing-sozed planes. The hole was simply too small: it was as large as from a 1-man plane which hit Pirelli center in Italy a few weeks before. See more here: > http://www.serendipity.li/wot/psyopnews1.htm > http://www.serendipity.li/wot/wtc_ch2.htm > http://www.serendipity.li/wtc.htm > and ascending. > > This is not at all original, i found a similar analysis a few monts after the fall on a german website dedicated to Mahatma Gandhi. > > --- > > Structural Audio is a composition of all information to create a sound by its source pieces. In a real world, you can decribe a sound by packing a musical score, a few instruments, and musicials which play them with their special style, in a huge box, and make them play on demand. :) In a computer world things are much easier. Since music is recorded using computers anyway, it is initally composed of a MIDI score, live wave recordings like vocals, and synthesis algorithms and data. By utilising this information available at creation, one can achieve high compression ratios compared to streaming formats like MP3 and OGG. Simplest examples of structural audio include MOD-like data formats, which contain a score and instrument wave data, but a simple pack of MIDI and a soundbank would also qualify. > > However, there's more to it. "Real" structural audio formats, like CSound and MPEG4-SA, allow for This sentence got cut off. > >> Yes, .NETs VM is in my opinion a much better thing than what >> Java VMs tend to be. I wonder if .NET isn't more in the direction >> of what you are talking about. > > > Not really. But since any VM supports reflection, any would theoretically do. Besides, most .NET VM always compile and never interpret - it doesn't take much more time to compile without any optimisations. MONO compiler shall be 2-stage: as soon as the function is called often enough, it is compiled with full optimisation. After a short while, source/bytecode need not be held in memory any longer - either because a function is used rarely and need not be optimised, or because it's optimised to 100%. This compile-only behaviour is fortunate for any use with repetitious code, especially if full optimisation can be assumed at once. > > -i. > |
August 08, 2003 Re: OT: JIT, VM, Sound, WTC. Re: Project feedback - debugger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Frank Wills | Frank Wills wrote:
> This sentence got cut off.
No, it didn't get cut off -- you must know i am a broken robot. I write all parts of a mail at once and i simply sent it off before writing it to the end. So here come the damaged paragraphs.
---
It could, if you would exactly know what data is constant and what not, by patching. Even better, since you can profit from a powerful optimiser. However, if you take generic matrix multiplication routine, you can have undeterminable variable parts, or you can have simple coefficients, esp. 0, which simplify the expression by orders of magnitude. That's why it makes sense to compile and optimise at run-time.
---
However, there's more to it. "Real" structural audio formats, like CSound and MPEG4-SA, allow you to store code for instrument syntesis, mixdown and post-processing. This is a lot more flexible.
A good thing about sound, is that you generally have all the score available at once, so you can predict, when exactly you need what code, and whether there are distinct constant parameters or plug-in chains, where a specialised and inlined version can be compiled. This is an area for infinite tuning, and i argue that it may give much higher performance than current systems using precompiled plug-ins, like Logic Audio, Cubase VST, and alike.
-i.
|
August 08, 2003 Re: Project feedback - debugger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Frank Wills | I found a funny thing: a platform-independant debugger, based upon LCC. Maybe hack up an LCC-based backend? :) http://www.cs.princeton.edu/software/lcc/cdb/ -i. |
August 08, 2003 Re: Project feedback - debugger | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ilya Minkov | Hey, thanks. I'll take a look at it.
Ilya Minkov wrote:
> I found a funny thing: a platform-independant debugger, based upon LCC. Maybe hack up an LCC-based backend? :)
>
> http://www.cs.princeton.edu/software/lcc/cdb/
>
> -i.
>
|
September 13, 2003 Re: Project feedback - debugger: Walter - extend debug data? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Frank Wills | "Frank Wills" <fdwills@sandarh.com> wrote in message news:bgum1t$18tq$1@digitaldaemon.com... > That explains what I've been seeing when I debug an app in Visual Studio. Char arrays show up as a large int value. Walter, is this something you could do? What is the current state of debug info? Yes, I can fix that. I just haven't spent much of any time on the debug info. |
Copyright © 1999-2021 by the D Language Foundation