There are two possible reasons for using inline assembler code :
1. For speed-critical portions of code. 2. For very low-level, machine-specific parts of the code.
So, if it's reason #2, then you can't merely translate the code, either to Pascal, or to your new target machine language, Sparc. For example, suppose the inline assembly code is an interrupt service routine for INT4 (COM1: serial port interrupt). You can't just translate this to another platform, because INT4 (if there is such a thing) will be unrelated, the serial port I/O addresses will be different, the serial port UART probably has different registers and modes, the CPU will definitely have different registers, etc., etc.
Good luck, you'll need it!
Joe.
-----Original Message----- From: Frank Heckenbach [SMTP:frank@g-n-u.de] Sent: Monday, February 18, 2002 4:51 PM To: gpc@gnu.de Subject: Re: Compiling inline assembly code
Anuradha wrote:
We have been trying to compile in-line assembler code in our pascal programs using gpc-20010623 .We are porting the sources from windows to sparc-sunsolaris 2.6 and we have some problems with compiling the asm code.The gas says that it is not able to recognise the opcodes "push","pop","cld"..
Erm, well, different processors use different kinds of assembler code. That's why assembler is considered low-level compared to Pascal.
Basically, you'll have to rewrite all your assembler code for any new processor. Or you translate it to Pascal, then you need only one version. (Since GPC is a Pascal compiler, I think I might mention this option ... ;-)
The link to Mr.Brennan's site given in the FAQ has a ~ and we are not able to reach the site.
Thanks for the hint. In the DJGPP FAQ, I found a new URL: http://www.delorie.com/djgpp/doc/brennan/brennan_att_inline_djgpp.html
BTW, I was misspelled (the `_djgpp' part was missing) or has moved -- at least since v2.30 of the FAQ which I have here (in case any of the DJGPP people are reading this, and it hasn't been fixed already).
Can you kindly tell us where we can get some help on compiling asm on sparc-sun-solaris.
No, I haven't had the need to program any asm on the Sparc. Have you searched the net?
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
There are two possible reasons for using inline assembler code :
- For speed-critical portions of code.
- For very low-level, machine-specific parts of the code.
So, if it's reason #2, then you can't merely translate the code, either to Pascal, or to your new target machine language, Sparc. For example, suppose the inline assembly code is an interrupt service routine for INT4 (COM1: serial port interrupt). You can't just translate this to another platform, because INT4 (if there is such a thing) will be unrelated, the serial port I/O addresses will be different, the serial port UART probably has different registers and modes, the CPU will definitely have different registers, etc., etc.
Maybe if the OP posts a sample here, we can determine if it is (1) or (2)
da Silva, Joe wrote:
There are two possible reasons for using inline assembler code :
- For speed-critical portions of code.
- For very low-level, machine-specific parts of the code.
So, if it's reason #2, then you can't merely translate the code, either to Pascal, or to your new target machine language, Sparc. For example, suppose the inline assembly code is an interrupt service routine for INT4 (COM1: serial port interrupt). You can't just translate this to another platform, because INT4 (if there is such a thing) will be unrelated, the serial port I/O addresses will be different, the serial port UART probably has different registers and modes, the CPU will definitely have different registers, etc., etc.
If you want to access serial devices, you can translate in to appropriate system calls, using termios etc. (might need a few C wrappers, but they can be written portably) and let the OS do the hardware access. At least outside of Dos/Windows, that's the usual way to do it (and often the only one, unless you want to have to run the program as root).
Frank
-
da Silva, Joe -
Frank Heckenbach -
marcov＠stack.nl