| View previous topic :: View next topic |
| Author |
Message |
Kristof Benes
Guest
|
 Posted: Fri Jun 20, 2008 1:11 am Post subject: Assembly Language vs. C |
 |
|
Hi All,
Having been a long time C programmer, and having dabbled in assembly,
I'm faced with an interesting dilemna. Now that I'm at the point where
I'm into paging and task switching, etc... I find that C sort of gets in
the way sometimes. The way that it makes function calls are inefficient
from a purely kernel perspective and the assembly code that it actually
generates is actually pretty hard to follow, not to mention almost
impossible to debug since I didnt actually "write" it. Although its
possible to write a kernel completely in C its been done several times
obviously, is it really ideal?
So, to the court of other, most of which more experienced OS Devers,
which is better in your opinion? C, ASM, or a mix? |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
Alexei A. Frounze
Guest
|
| Posted: Fri Jun 20, 2008 1:11 am Post subject: Re: Assembly Language vs. C |
|
|
On Jun 19, 1:11 pm, Kristof Benes <ch...@nospammaricopacomputer.com>
wrote:
| Quote: |
Hi All,
Having been a long time C programmer, and having dabbled in assembly,
I'm faced with an interesting dilemna. Now that I'm at the point where
I'm into paging and task switching, etc... I find that C sort of gets in
the way sometimes. The way that it makes function calls are inefficient
from a purely kernel perspective and the assembly code that it actually
generates is actually pretty hard to follow, not to mention almost
impossible to debug since I didnt actually "write" it. Although its
possible to write a kernel completely in C its been done several times
obviously, is it really ideal?
So, to the court of other, most of which more experienced OS Devers,
which is better in your opinion? C, ASM, or a mix?
|
You always have a mix. You may try writing smaller C functions for the
debugging purpose and make them conditionally inline for speed (that
is, non-inlined in debug version, inlined otherwise). Other than that
you may want to:
- refresh your C so you do fewer bad things in C
- refresh your Asm so you follow it better
- develop as much of code in a normal environment for application
development as possible thus reducing the need to debug things the
hard way (i.e. w/o a debugger (for HLL code or symbolic), w/
disassembler)
Alex |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Alexei A. Frounze
Guest
|
| Posted: Fri Jun 20, 2008 5:49 am Post subject: Re: Assembly Language vs. C |
|
|
On Jun 19, 7:21 pm, "Ciaran Keating" <cia...@amadantech.com> wrote:
| Quote: |
On Fri, 20 Jun 2008 06:34:40 +1000, Alexei A. Frounze
alexfrun...@gmail.com> wrote:
On Jun 19, 1:11 pm, Kristof Benes <ch...@nospammaricopacomputer.com
wrote:
the assembly code that it actually
generates is actually pretty hard to follow, not to mention almost
impossible to debug since I didnt actually "write" it.
- develop as much of code in a normal environment for application
development as possible thus reducing the need to debug things the
hard way (i.e. w/o a debugger (for HLL code or symbolic), w/
disassembler)
If you really don't want to step through the compiler-generated assembly
code then it might be worth your while to build a C-level debugger and
connect it either to bochs (or whatever) or to a COM port on real
hardware. I've made a start on that - I've got a basic GUI debugger that
talks to bochs, but so far it still only operates at the assembler level.
But note that I said it "might" be worth your while... I found I was
spending so much time on my debugger that I was neglecting the OS itself,
and so I put the debugger project away for a while.
|
I think I've managed to write the low level code (C or Asm) well
enough so I don't need to debug it much. I often can see bugs right in
the source (or in disassembly). Surely, it hadn't been given, and I
did a lot of debugging. But you can master it in just about 5+ years
and then the debugging is a rare and fun exercise 'cause you stop
getting simple bugs. :)
Alex |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Ciaran Keating
Guest
|
| Posted: Fri Jun 20, 2008 7:21 am Post subject: Re: Assembly Language vs. C |
|
|
On Fri, 20 Jun 2008 06:34:40 +1000, Alexei A. Frounze
<alexfrunews@gmail.com> wrote:
| Quote: |
On Jun 19, 1:11 pm, Kristof Benes <ch...@nospammaricopacomputer.com
wrote:
the assembly code that it actually
generates is actually pretty hard to follow, not to mention almost
impossible to debug since I didnt actually "write" it.
- develop as much of code in a normal environment for application
development as possible thus reducing the need to debug things the
hard way (i.e. w/o a debugger (for HLL code or symbolic), w/
disassembler)
|
If you really don't want to step through the compiler-generated assembly
code then it might be worth your while to build a C-level debugger and
connect it either to bochs (or whatever) or to a COM port on real
hardware. I've made a start on that - I've got a basic GUI debugger that
talks to bochs, but so far it still only operates at the assembler level.
But note that I said it "might" be worth your while... I found I was
spending so much time on my debugger that I was neglecting the OS itself,
and so I put the debugger project away for a while.
--
Ciaran Keating
Amadan Technologies |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Alexei A. Frounze
Guest
|
| Posted: Fri Jun 20, 2008 8:58 am Post subject: Re: Assembly Language vs. C |
|
|
On Jun 19, 11:57 pm, Kristof Benes
<ch...@maricopa.nospam.computer.com> wrote:
| Quote: |
Alexei A. Frounze wrote:
On Jun 19, 7:21 pm, "Ciaran Keating" <cia...@amadantech.com> wrote:
On Fri, 20 Jun 2008 06:34:40 +1000, Alexei A. Frounze
alexfrun...@gmail.com> wrote:
On Jun 19, 1:11 pm, Kristof Benes <ch...@nospammaricopacomputer.com
wrote:
the assembly code that it actually
generates is actually pretty hard to follow, not to mention almost
impossible to debug since I didnt actually "write" it.
- develop as much of code in a normal environment for application
development as possible thus reducing the need to debug things the
hard way (i.e. w/o a debugger (for HLL code or symbolic), w/
disassembler)
If you really don't want to step through the compiler-generated assembly
code then it might be worth your while to build a C-level debugger and
connect it either to bochs (or whatever) or to a COM port on real
hardware. I've made a start on that - I've got a basic GUI debugger that
talks to bochs, but so far it still only operates at the assembler level.
But note that I said it "might" be worth your while... I found I was
spending so much time on my debugger that I was neglecting the OS itself,
and so I put the debugger project away for a while.
I think I've managed to write the low level code (C or Asm) well
enough so I don't need to debug it much. I often can see bugs right in
the source (or in disassembly). Surely, it hadn't been given, and I
did a lot of debugging. But you can master it in just about 5+ years
and then the debugging is a rare and fun exercise 'cause you stop
getting simple bugs. :)
Alex
Hey Alex,
Yeah most of the bugs I get are 1 - misappropriation of the stack
(syscalls and task switching) or 2 - device responding differently than
what I thought it would do. Like my freakin ATA driver for instance.
Of course every now and then I make a typo :-)
I've been writing software professionally for the financial industry for
a little over 8 years. I started though long before that with a
computer thats prompt was on a blue TV screen with white text that said
simply:
READY
Of course I have made a few fantasic blunders, one being the shared
buffer for two processes and wondering why it kept mixing up the
characters. But then figuring out why it happens is pretty satisfying.
Some of this stuff is just getting too nuts to try to follow ASM
generated by C code. That or it works in Bochs and not on real hardware.
I guess I was just phishing to see if anyone could give a convincing ASM
only argument.
|
Well, to my dad ASM is the only option for a variety of reasons:
- he doesn't write too much where ASM would be an overkill, although
his programs are many thousands of lines and many KBs of compiled code
- it would take him a lot of time to study something more vague like C
with its variable type sizes
- he wants and needs to fit the code and data into a small ROM/EEPROM/
Flash and have small stack consumption which lets him move the code
around different types of microcontrollers (that carry different
amount of memory on chip and the internal RAM is only about 128 bytes)
and not have size or cost issues. Compiled C code for microcontrollers
is insanely big. He'd also need to master writing compact C code and
ensure that no useless crap gets linked (i.e. parts of the standard C
library).
- he's got A LOT of ASM code that's been tested and is known to work,
so, it's easy to carry on doing everything in ASM
- in some places he needs it fast and in microcontrollers for that ASM
is the best choice
- he has several debugging options: hardware debugger and my software
debugger/emulator. The latter supports symbolic debugging to some
extent and I believe the former does it too. His programs are well
structured and commented. So, debugging isn't a big problem.
Occasionally, he writes some simple tools in Pascal or asks me to help
out.
You wanted this argument? Here, you have it. :)
Anyways, think what you really need for the project, what are the most
appropriate options for you now, what you can do to alleviate the
existing problems, and then think how your decisions will affect you
and your code in the future. Sometimes you're better of with fast
code, but maybe not very simple or clean. At other times you want very
compact code, but again maybe not very simple and clean. At yet other
times you really want the code simple and clean, so it can be
developed further by yourself and others and not seriously overhauled
or simply thrown away. Sometimes you want it to be suitable for
testing, that is, the test can be interfaced with the code, can drive
it, can peek at various states and can have the appropriate inputs and
outputs for interacting with the tester. All of those things need to
be considered.
Alex |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Rod Pemberton
Guest
|
| Posted: Fri Jun 20, 2008 11:04 am Post subject: Re: Assembly Language vs. C |
|
|
"Kristof Benes" <chris@nospammaricopacomputer.com> wrote in message
news:g3eegu$hod$1@news2.open-news-network.org...
| Quote: |
Having been a long time C programmer, and having dabbled in assembly,
I'm faced with an interesting dilemna. Now that I'm at the point where
I'm into paging and task switching, etc...
|
Not there yet... Not sure if I need either, yet... (Although I like being
able to have multiple windows open when using the Internet, for the most
part I prefer CLI's and DOS...)
| Quote: |
I find that C sort of gets in
the way sometimes.
|
Yes.
| Quote: |
The way that it makes function calls are inefficient
from a purely kernel perspective
|
Yes.
| Quote: |
and the assembly code that it actually
generates is actually pretty hard to follow,
|
GCC -S without other optimizations... assume the optimizations work
without ever looking. There are fewer headaches that way. :-)
| Quote: |
not to mention almost
impossible to debug since I didnt actually "write" it.
|
I've only used a true debugger a few times in my life... I prefer
printf/sprintf etc. for C and hex output routines for assembly. I prefer
real hardware testing to Bochs, QEMU. I will eventually use them because
they do find some non-obvious issues (as Alexei has demonstrated), but they
have their own bugs too (as Ben has demonstrated).
| Quote: |
Although its
possible to write a kernel completely in C its been done several times
obviously, is it really ideal?
|
Probably not, but then assembly probably isn't the perfect choice either.
I chose C because:
1) I prefer C to assembly.
2) one can generate good assembly from C even without optimization (time
with GCC -S)
3) IMO variables, flow control, general programming, etc. are much easier
in C
4) starting from C (and DOS) allowed me to start developing the OS right
away
5) many of the problems of generating correct assembly have been resolved
by the compiler implementor
C has some disadvantages compared to assembly:
1) you may need to work around C's type system (casts, multiple type
conversions, etc.) to do some things needed for OS development
2) there is no native C support for interrupts
3) while C has much RISC functionality, there is no CISC functionality -
so some assembly is required, literally, for those special cpu instructions
4) you're trusting all of the compiler and (perhaps) some of the libraries
to be free of bugs, interrupt calls, OS dependencies, etc. This is a much
larger code base to trust than an assembler and/or disassembler.
5) you'll have to deal with C's internal implementation
Assembly has some disadvantages too:
1) not easy to keep track variables or register use
2) x86 assembly instructions have side effects
3) if you code 16-bit, how do you port to 32-bit? I.e., it might be
better not to code assembly, but to code in assembler macro's...
4) you'll need to write your own low level routines upfront (libraries,
flow control, etc.)
| Quote: |
So, to the court of other, most of which more experienced OS Devers,
which is better in your opinion? C, ASM, or a mix?
|
I'm not sure if there's a best way. I see drawbacks, like those above, for
both. My preference is for C for as much as possible - even if it takes a
bit more work. I don't like trying to keep track of (unnamed) variables
which is why I like C over assembly or FORTH. However, C's type system
(post K&R) makes it difficult to do some things which are easy in assembly
(integer-pointer conversion, pointer arithmetic, integer size conversions,
etc.)
mix? Like Chewy's B0?
http://chewy509.110mb.com/b0.html
As for my personal OS, I can tell you what problems I've run into. First,
it's mostly C (for two compilers) with some C inlined assembly and one piece
of (non-C) assembly. The problems I've run into are:
1) can't find way to get C compiler or linker to place multi-boot header in
C into first 8k
(The DOS DPMI C startup code is too large. And, I'm not using a linker
script... yet.)
2) some basic assembly instructions, like 'cli' and 'sti', are actually
compiler dependent and have their own C "intrinsic" (e.g., OpenWatcom needs
'cld')
3) a couple of rare combinations of optimizations with GCC (DJGPP) produce
kernel code that won't execute (tested for robustness)
4) one OS independent function in OpenWatcom's C library had a difficult to
locate bug... and required changes to my OS.
5) OpenWatcom's -wx (v1.3) catches very few errors compared to
GCC -Wall -ansi -pedantic
6) GCC fails to catch many signed vs. unsigned errors - both parameters and
missing casts (A rare situation where OpenWatcom is better...)
7) GCC (32-bit DJGPP) generates better code for 'int' than 'unsigned long'
despite being the same size... etc.
 volatile keyword use is not consistent across compilers...
9) each compiler uses a different memory model
10) interrupts end up in an ugly mess of C and assembly
11) many parts of the C libraries are OS independent (maybe 30%), but
nowhere near as much as "C is portable" pedants proclaim (80-100%).
12) without total control of the C compiler and/or toolchain, you loose
control of some of the code used in your OS. (e.g., security issue, bugs, or
compiler limitations - such as type of procedure return: ret,retf,iret)
13) if your compiler is 32-bits (and/or 64-bits) only, how do you implement
16-bit code to make VESA BIOS calls or a bootloader? (assembly, interpreter
in C, etc.)
It sounds like you're much further along...
Rod Pemberton |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Rod Pemberton
Guest
|
| Posted: Fri Jun 20, 2008 11:04 am Post subject: Re: Assembly Language vs. C |
|
|
"Kristof Benes" <chris@maricopa.nospam.computer.com> wrote in message
news:g3fkcl$5ec$1@aioe.org...
| Quote: |
I guess I was just phishing to see if anyone could give a convincing ASM
only argument.
|
Not I, maybe Ben Lunt or Wolfgang Kern... Alexei Frounze?
Rod Pemberton |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Wolfgang Kern
Guest
|
| Posted: Fri Jun 20, 2008 11:04 am Post subject: Re: Assembly Language vs. C |
|
|
I wrote:
.....
| Quote: |
* The freedom to decide (ie: ignore detouring/bloating C-conventions).
* Totally independency from development environment.
* Opportunity to create code modules which doesn't need to be
'linked' or 're-allocated' (just run it where you loaded it).
* Code-Size... ASM is usually half related to C-created code.
* No guessing... without using Libs, you know in detail what you wrote.
* True facts... No abstractions, everything become transparent.
... and perhaps a few more pros.
|
and forgot to mention the biggest advantage:
* Not bound to Variable-types ...
I actually have 32 different numeric- beside FPU-types and bit-strings,
eight of them can be defined by the user (up to 512 bytes).
__
wolfgang |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Wolfgang Kern
Guest
|
| Posted: Fri Jun 20, 2008 11:04 am Post subject: Re: Assembly Language vs. C |
|
|
Kristof Benes said:
| Quote: |
Yeah most of the bugs I get are 1 - misappropriation of the stack
(syscalls and task switching) or 2 - device responding differently than
what I thought it would do. Like my freakin ATA driver for instance.
Of course every now and then I make a typo 
|
You aren't alone with this, it took me too some time to figure out how
the hardware really works (docs/specs aren't written too daubtfree)
| Quote: |
I've been writing software professionally for the financial industry for
a little over 8 years. I started though long before that with a
computer thats prompt was on a blue TV screen with white text that said
simply:
READY
Yeah. Good old C64 times |
| Quote: |
Of course I have made a few fantasic blunders, one being the shared
buffer for two processes and wondering why it kept mixing up the
characters. But then figuring out why it happens is pretty satisfying.
Some of this stuff is just getting too nuts to try to follow ASM
generated by C code. That or it works in Bochs and not on real hardware.
I guess I was just phishing to see if anyone could give a convincing
ASM only argument.
|
As a machine code freak, I see many convincing advantages in
using low level programming for OS-kernels:
* The freedom to decide (ie: ignore detouring/bloating C-conventions).
* Totally independency from development environment.
* Opportunity to create code modules which doesn't need to be
'linked' or 're-allocated' (just run it where you loaded it).
* Code-Size... ASM is usually half related to C-created code.
* No guessing... without using Libs, you know in detail what you wrote.
* True facts... No abstractions, everything become transparent.
.... and perhaps a few more pros.
A decent assembler/disassembler-pair with a built in debugger which
covers all exceptions and support breakpoints of any kind, and work
in all (RM/PM16/PM32 and perhaps also VM86 and Unreal/Bigreal) modes
would offer an incredible OS development opportunity.
But I haven't seen any tool like this. So I first wrote my own (editable
on the hex-side) disassembler, then a debugger,... and finally the OS.
I once started on a DOS-environment with debug and PowerBasic, but my
OS grew up step by step and became stand alone since many years,
so all newer versions of it were already created with previous ones.
You will hear also counter-arguments against LL-coded cores:
*Portability (anyway just a fiction in my view)
*Maintainability (guess my thoughts on "alter includes/recompile"...)
*Compatibilty (compatible to windoze/L'unix ? why not use them then)
__
wolfgang |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Kristof Benes
Guest
|
| Posted: Fri Jun 20, 2008 11:04 am Post subject: Re: Assembly Language vs. C |
|
|
Alexei A. Frounze wrote:
| Quote: |
On Jun 19, 7:21 pm, "Ciaran Keating" <cia...@amadantech.com> wrote:
On Fri, 20 Jun 2008 06:34:40 +1000, Alexei A. Frounze
alexfrun...@gmail.com> wrote:
On Jun 19, 1:11 pm, Kristof Benes <ch...@nospammaricopacomputer.com
wrote:
the assembly code that it actually
generates is actually pretty hard to follow, not to mention almost
impossible to debug since I didnt actually "write" it.
- develop as much of code in a normal environment for application
development as possible thus reducing the need to debug things the
hard way (i.e. w/o a debugger (for HLL code or symbolic), w/
disassembler)
If you really don't want to step through the compiler-generated assembly
code then it might be worth your while to build a C-level debugger and
connect it either to bochs (or whatever) or to a COM port on real
hardware. I've made a start on that - I've got a basic GUI debugger that
talks to bochs, but so far it still only operates at the assembler level.
But note that I said it "might" be worth your while... I found I was
spending so much time on my debugger that I was neglecting the OS itself,
and so I put the debugger project away for a while.
I think I've managed to write the low level code (C or Asm) well
enough so I don't need to debug it much. I often can see bugs right in
the source (or in disassembly). Surely, it hadn't been given, and I
did a lot of debugging. But you can master it in just about 5+ years
and then the debugging is a rare and fun exercise 'cause you stop
getting simple bugs. :)
Alex
Hey Alex, |
Yeah most of the bugs I get are 1 - misappropriation of the stack
(syscalls and task switching) or 2 - device responding differently than
what I thought it would do. Like my freakin ATA driver for instance.
Of course every now and then I make a typo :-)
I've been writing software professionally for the financial industry for
a little over 8 years. I started though long before that with a
computer thats prompt was on a blue TV screen with white text that said
simply:
READY
Of course I have made a few fantasic blunders, one being the shared
buffer for two processes and wondering why it kept mixing up the
characters. But then figuring out why it happens is pretty satisfying.
Some of this stuff is just getting too nuts to try to follow ASM
generated by C code. That or it works in Bochs and not on real hardware.
I guess I was just phishing to see if anyone could give a convincing ASM
only argument. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
octavio
Guest
|
| Posted: Fri Jun 20, 2008 5:47 pm Post subject: Re: Assembly Language vs. C |
|
|
| Quote: |
which is better in your opinion? C, ASM, or a mix?
|
For system programing ASM is better (my opinion)
there are various operating systems written 100% in ASM by just one
programmer
(OctaOs,Menuetos,SolarOS,Dexos...).Using only C is not possible you
always will need some assembly code.C is better for writting another
unix clone (copy paste from linux) but for your own work
Asm is easier to debug and faster to work with it.
I would only recommend C if you are much better programing in C than
in assembly but to write a OS you will need to master assembly
programing. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Benjamin David Lunt
Guest
|
| Posted: Fri Jun 20, 2008 11:05 pm Post subject: Re: Assembly Language vs. C |
|
|
"Rod Pemberton" <do_not_have@nohavenot.cmm> wrote in message
news:g3fr1r$u5n$1@aioe.org...
| Quote: |
"Kristof Benes" <chris@maricopa.nospam.computer.com> wrote in message
news:g3fkcl$5ec$1@aioe.org...
I guess I was just phishing to see if anyone could give a convincing ASM
only argument.
Not I, maybe Ben Lunt or Wolfgang Kern... Alexei Frounze?
|
My boot sectors(s) and loader.sys files are in assembly. The
loader.sys file could be in C if I wanted to put the effort into
finding a C compiler that would output the format I wanted.
Very little of my kernel is assembly. The inpx/outpx routines,
a few CPU related routines, and a few math routines. However,
my task/thread switcher is all C, except for the ISR, which
simply places all the register values into an array, calls
the C coded task switcher, then on return, restores all the
registers from the array.
If I could get a C compiler to work for me, I would do all the
code in C. I make more mistakes than the C compiler would make.
However, I haven't found a C compiler than will switch between
real mode code and protected mode code at will.
Ben |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Alexei A. Frounze
Guest
|
| Posted: Sat Jun 21, 2008 3:56 am Post subject: Re: Assembly Language vs. C |
|
|
On Jun 20, 5:30 pm, "Ciaran Keating" <cia...@amadantech.com> wrote:
| Quote: |
On Fri, 20 Jun 2008 15:49:56 +1000, Alexei A. Frounze
alexfrun...@gmail.com> wrote:
On Jun 19, 7:21 pm, "Ciaran Keating" <cia...@amadantech.com> wrote:
If you really don't want to step through the compiler-generated assembly
code then it might be worth your while to build a C-level debugger and
I think I've managed to write the low level code (C or Asm) well
enough so I don't need to debug it much. I often can see bugs right in
the source (or in disassembly).
Sorry, Alex... I assumed you didn't need hints from me since you've been
at this a long time. My suggestion was really for Kristof but I replied to
your post to keep some continuity.
|
Um... Sorry for what?
| Quote: |
And thanks, Kristof - inspired by your question I spent a few hours last
night figuring out how to get line numbers out of the .pdb file so I can
add C-level stepping to my debugger. (.pdb because I use Visual C++.)
But you can master it in just about 5+ years
Indeed, patience is absolutely essential in this game!
|
:)
Alex |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Ciaran Keating
Guest
|
| Posted: Sat Jun 21, 2008 5:30 am Post subject: Re: Assembly Language vs. C |
|
|
On Fri, 20 Jun 2008 15:49:56 +1000, Alexei A. Frounze
<alexfrunews@gmail.com> wrote:
| Quote: |
On Jun 19, 7:21 pm, "Ciaran Keating" <cia...@amadantech.com> wrote:
If you really don't want to step through the compiler-generated assembly
code then it might be worth your while to build a C-level debugger and
I think I've managed to write the low level code (C or Asm) well
enough so I don't need to debug it much. I often can see bugs right in
the source (or in disassembly).
|
Sorry, Alex... I assumed you didn't need hints from me since you've been
at this a long time. My suggestion was really for Kristof but I replied to
your post to keep some continuity.
And thanks, Kristof - inspired by your question I spent a few hours last
night figuring out how to get line numbers out of the .pdb file so I can
add C-level stepping to my debugger. (.pdb because I use Visual C++.)
| Quote: |
But you can master it in just about 5+ years
|
Indeed, patience is absolutely essential in this game!
--
Ciaran Keating
Amadan Technologies |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Alexei A. Frounze
Guest
|
| Posted: Tue Jun 24, 2008 2:19 am Post subject: Re: Assembly Language vs. C |
|
|
On Jun 23, 5:10 pm, "Ciaran Keating" <cia...@amadantech.com> wrote:
| Quote: |
On Sat, 21 Jun 2008 13:56:37 +1000, Alexei A. Frounze
alexfrun...@gmail.com> wrote:
On Jun 20, 5:30 pm, "Ciaran Keating" <cia...@amadantech.com> wrote:
Sorry, Alex... I assumed you didn't need hints from me since you've been
at this a long time. My suggestion was really for Kristof but I replied
to
your post to keep some continuity.
Um... Sorry for what?
I thought maybe my post sounded a bit like teaching my granny to suck
eggs. You don't need tips from me on how to debug your code!
|
Nah, I think we're pretty nice folks to get insulted that easily, even
more so since we have "virtually" known each other for a while. :)
Alex |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
130 Attacks blocked
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
