Global variables and HP-GCC
in [HP48]
|
Prev: New HP 50G Owner
Next: EMU48
From: Claudio Lapilli on 31 Aug 2006 12:23 John H Meyers wrote: > On Wed, 30 Aug 2006 19:33:45 -0500, Claudio Lapilli wrote: > > >> Is there any way of accessing global variables with HP-GCC? > > > Yes, look for the sat_dir... functions. You can traverse subdirectories > > and read variables. However, this is read-only, you cannot write to > > these variables (at least for now, we'll try to add this feature > > in the future). > > Could you implement a "server" -- i.e. an RPL program > which would accept any commands to be executed in RPL mode > (using a new or saved stack, say), > then return to where you suspended HPGCC mode? > That would be: 1) difficult to implement 2) against the whole idea of hpgcc (running native code). Let me explain a little more the second point: If you want to run saturn-emulated-interpreted commands, then don't use hpgcc. The whole idea of hpgcc is to write native ARM code, therefore it seems more logical to write native routines to manipulate objects in ARM rather than going back to the emulated saturn. > If you had that, then you could have HPGCC programs > perform any desired RPL commands, and would not need > to add individual specific features to HPGCC. As it is now, hpgcc can manipulate saturn objects pretty well (provided you have the knowledge needed to do it, of course). What hpgcc can't do is to use the CAS, but if you need the CAS, then use it from the calculator, you don't really need hpgcc for that. Storing objects in userob is an interesting feature that may be added in a future release, but don't expect any major improvement in the interaction RPL <-> C. Claudio
From: John H Meyers on 31 Aug 2006 13:50 On Thu, 31 Aug 2006 11:23:41 -0500, Claudio Lapilli wrote: > That would be: > 1) difficult to implement > 2) against the whole idea of hpgcc (running native code). > > Let me explain a little more the second point: If you want to run > saturn-emulated-interpreted commands, then don't use hpgcc. The whole > idea of hpgcc is to write native ARM code, therefore it seems more > logical to write native routines to manipulate objects in ARM rather > than going back to the emulated saturn. > > As it is now, hpgcc can manipulate saturn objects pretty well (provided > you have the knowledge needed to do it, of course). What hpgcc can't do > is to use the CAS, but if you need the CAS, then use it from the > calculator, you don't really need hpgcc for that. > Storing objects in userob is an interesting feature that may be added > in a future release, but don't expect any major improvement in the > interaction RPL <-> C. I was thinking that among the few thousand already built-in RPL functions and commands, there might be some which are not calculation-intensive, which would not benefit at all from having direct access to the ARM CPU, and which instead might be useful for having already been completely developed, debugged, and working with the already-existing RPL. I'm sorry that I lack the experience of working with HPGCC; in my imagination, I depicted that it might provide something like an alternative to the RPL "Code" object (containing Saturn CPU code), which instead might contain an interface to ARM code, with suitable aids enabling direct access to the memory where RPL objects reside, as well as the potential to take over entirely from the RPL OS and thus simply bypass it entirely. It would be possible in RPL to allocate a large chunk of memory which could be used by HPGCC for anything it wants (perhaps even its own file system), disguised as a "Library Data" object (which is opaque to UserRPL, although it can be stored anywhere as an RPL object). Well, thanks again for the attempt to enlighten me (though I probably remain in the dark, or perhaps the Dark Ages :) Best wishes to you and all HPGCC developers. [r->] [OFF]
From: Claudio Lapilli on 31 Aug 2006 18:56 John H Meyers wrote: > On Thu, 31 Aug 2006 11:23:41 -0500, Claudio Lapilli wrote: > > > That would be: > > 1) difficult to implement > > 2) against the whole idea of hpgcc (running native code). > > > > Let me explain a little more the second point: If you want to run > > saturn-emulated-interpreted commands, then don't use hpgcc. The whole > > idea of hpgcc is to write native ARM code, therefore it seems more > > logical to write native routines to manipulate objects in ARM rather > > than going back to the emulated saturn. > > > > As it is now, hpgcc can manipulate saturn objects pretty well (provided > > you have the knowledge needed to do it, of course). What hpgcc can't do > > is to use the CAS, but if you need the CAS, then use it from the > > calculator, you don't really need hpgcc for that. > > Storing objects in userob is an interesting feature that may be added > > in a future release, but don't expect any major improvement in the > > interaction RPL <-> C. > > I was thinking that among the few thousand already built-in > RPL functions and commands, there might be some which are > not calculation-intensive, which would not benefit at all > from having direct access to the ARM CPU, and which instead > might be useful for having already been completely developed, > debugged, and working with the already-existing RPL. > > I'm sorry that I lack the experience of working with HPGCC; > in my imagination, I depicted that it might provide something > like an alternative to the RPL "Code" object > (containing Saturn CPU code), which instead might contain > an interface to ARM code, with suitable aids enabling > direct access to the memory where RPL objects reside, > as well as the potential to take over entirely > from the RPL OS and thus simply bypass it entirely. It *does* work like a CODE object, and just like a code object you need to return to sysrpl, use the CAS and then restart another code object (or the same). You can't access the CAS from saturn assembler either (maybe just a few basic functions, but in general you can't). > > It would be possible in RPL to allocate a large chunk > of memory which could be used by HPGCC for anything it wants > (perhaps even its own file system), disguised as > a "Library Data" object (which is opaque to UserRPL, > although it can be stored anywhere as an RPL object). If you need to store permanent data, it is perfectly feasible (and quite easy to do) to allocate a HXS string, libdata or any other 'string' object (from sysrpl) with enough space and overwrite it (from C) with any arbitrary data you want. Maybe I wasn't clear when I said 'read-only'. What I meant is that you can't create new variables or change the size of existing objects in USEROB (you can create new objects in TEMPOB, though), but nothing prevents you from overwriting their contents, changing their type, etc. Of course, that kind of low-level manipulation is not recommended (an invitation to a TTRM unless you are an old-timer sysrpl wizard) but perfectly possible to achieve what you described above. There are no new features needed to do that, just someone to sit down and code it :-). Claudio
From: am on 1 Sep 2006 13:06 Thanks for your answers. After some crashes, it seems I've managed to write some working code. Check the following example program, it draws a nice cubic on a patterned background. I needed a way to access PICT because I am writing a simulation of Conway's Game of Life. Being able to read from PICT means that one can draw a starting pattern with the calc's standard software, then run the program and watch the pattern evolve at high speed (so I don't have to write a pattern editor, eheh). On hpcalc.org there's a nice program that does this, written in Saturn assembly, but it seems to be not fully compatible with the bigger screen of the 49g+ (and, though very fast, it is still slower than what hpgcc achieves even in slow mode). Do you guys at hpgcc think that functions to load/manipulate grobs should be included in hpgcc? As you can see from their importance in the game of life program, such functions could prove to be very useful to provide graphic input to a program. Moreover, grobs can be sent to infrared printers. (After running the following program, press (in RPN mode) left to watch PICT.) /* * grob.c - GROB editing functions * Copyright (C) 2006 Andrea Molteni <andreamolteni(a)yahoo.it> * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. */ /* * GROB data structure * --------+---------+--------------------------------- * offset | nibbles | * --------+---------+--------------------------------- * 0x00 | 5 | prologue, 0x02B1E * 0x05 | 5 | size (not counting the prologue) * 0x0A | 5 | height (pixels) * 0x0F | 5 | width (pixels) * 0x14 | size-15 | pixel data, in reversed nibbles * --------+---------+--------------------------------- * Each row of pixel data is padded as needed to obtain an even number * of nibbles per row. */ #include <saturn.h> #define SAT_GDISP 0x806E4 #define sat_grob_get_size(grob_addr) sat_peek((grob_addr) + 0x5, 5) #define sat_grob_get_height(grob_addr) sat_peek((grob_addr) + 0xA, 5) #define sat_grob_get_width(grob_addr) sat_peek((grob_addr) + 0xF, 5) void sat_grob_clear(int grob_addr) { register int p = grob_addr + 0x14; grob_addr += sat_grob_get_size(grob_addr) + 0x5; for (; p < grob_addr; p += 2) sat_poke(p, 0, 2); } void sat_grob_draw_pixel(int grob_addr, int x, int y) { register int width = (sat_grob_get_width(grob_addr) + 7) >> 3 << 1; register int nibble = grob_addr + 0x14 + (y * width) + (x >> 2); sat_poke(nibble, sat_peek(nibble, 1) | (1 << (x & 3)), 1); } int sat_grob_get_pixel(int grob_addr, int x, int y) { register int width = (sat_peek(grob_addr + 0xF, 5) + 7) >> 3 << 1; register int nibble = grob_addr + 0x14 + (y * width) + (x >> 2); return (sat_peek(nibble, 1) >> (x & 3)) & 1; } int main() { int x, y; int pict_addr = sat_peek_sat_addr(SAT_GDISP); int height = sat_grob_get_height(pict_addr); int width = sat_grob_get_width(pict_addr); /* Just an example, the following code is not optimized. */ #define X ((x-width/2)/8.) #define Y ((height/2-y)/8.) sat_grob_clear(pict_addr); for (y = 0; y < height; y++) for (x = 0; x < width; x++) if (Y <= X*(X-4)*(X+4)/12 || (x+y)%2) sat_grob_draw_pixel(pict_addr, x, y); return 0; }
From: peti314 on 1 Sep 2006 14:54
> I needed a way to access PICT because I am writing a simulation of > Conway's Game of Life. I was trying to do the exact same thing, but unfortunately the project got stalled because of some real life duties. Now that you're writing a Life simulator, I don't have to finish it. :) I hope you can find something useful in the source, even though it's sloppily written, unoptimized, undocumented, and probably buggy as well. You can get it from: http://songokou.web.elte.hu/life.c and http://songokou.web.elte.hu/life!.c Could you be so kind as to try both versions and report any unexpected behavior? > Being able to read from PICT means that one can > draw a starting pattern with the calc's standard software, then run the > program and watch the pattern evolve at high speed (so I don't have to > write a pattern editor, eheh). My program already includes a very primitive editor (well, you can move with the cursor and toggle the pixels), and I had further plans to have a pattern library (to be able to insert some simple patterns like gliders or *WSSs), copy and paste functionality, to have a simple filer to load pattern definitions from SD card etc. - but it's unlikely that I'll ever get to implementing these features. > On hpcalc.org there's a nice program > that does this, written in Saturn assembly, but it seems to be not > fully compatible with the bigger screen of the 49g+ (and, though very > fast, it is still slower than what hpgcc achieves even in slow mode). How fast is your program? I couldn't get out more than 5 fps from my (admittedly not optimal) algorithm. Thanks for your time: Peter Juhasz |