Shop OBEX P1 Docs P2 Docs Learn Events
Spin2 Interpreter - Page 8 — Parallax Forums

Spin2 Interpreter

1234568»

Comments

  • cgraceycgracey Posts: 14,134
    edited 2019-07-30 23:38
    Rayman wrote: »
    Would this problem be resolved if there were a "HUBGET" instruction that would return the clock settings?

    Yes, but then each language would require its own function. It's much simpler if we just put it in a fixed location.
    Chip, now is the time for us to work out these addresses which could be $04,$08 or $F8 and $FC even as it is still easily reached with un-augmented rdlong imediate. P1 Spin reserved the first 16 bytes anyway.

    My original addresses were mainly for some functionality and I always had the option of changing it later. This has nothing to do with the ROM though, because what's in ROM, stays in ROM.

    We've got a Las Vegas ROM, I agree.

    It seems that people really want $00 allocated as a warm reset start or null pointer trap. To me, once booting has occurred, there's no going back. If you want to reboot, you need to reset the chip, not just launch a cog again from $00. Corrupted memory is probably why somebody would want to do a warm reset, but without a reboot, the memory remains corrupted.
  • evanhevanh Posts: 15,827
    edited 2019-07-30 23:52
    Dave Hein wrote: »
    Thanks, I had missed that. I should have read it more carefully. I think I quit reading it after the first couple of lines where it looked like he was still pushing his proposal. My previous response was actually more about evanh's proposal to change loadp2. I don't understand the need for the change. Maybe he'll explain it when he has a chance.

    I was pretty much against any change at the outset.

    It wasn't until I realised how separate the two issues really were, by Chip presenting a way to disentangle them, that I felt any desire for a change. You'd have to read all I've written in this conversation, and you can clearly see my only focus was the handover issue - https://forums.parallax.com/discussion/comment/1474393/#Comment_1474393

    EDIT: The nice thing with doing the RCFAST handover is it has no impact on any mailbox proposals, because it eliminates the loader's dependence on the mailboxes.

  • jmgjmg Posts: 15,169
    cgracey wrote: »
    It seems that people really want $00 allocated as a warm reset start or null pointer trap. To me, once booting has occurred, there's no going back. If you want to reboot, you need to reset the chip, not just launch a cog again from $00. Corrupted memory is probably why somebody would want to do a warm reset, but without a reboot, the memory remains corrupted.

    Yes and no. A full chip reset, takes a long time. There are cases where someone may want to reload a memory image, and re-launch without having the whole P2 grind to a halt.
    With 8 COG's I'd have expected being able to (re)start any cog is an important sales feature.

  • cgraceycgracey Posts: 14,134
    jmg wrote: »
    cgracey wrote: »
    It seems that people really want $00 allocated as a warm reset start or null pointer trap. To me, once booting has occurred, there's no going back. If you want to reboot, you need to reset the chip, not just launch a cog again from $00. Corrupted memory is probably why somebody would want to do a warm reset, but without a reboot, the memory remains corrupted.

    Yes and no. A full chip reset, takes a long time. There are cases where someone may want to reload a memory image, and re-launch without having the whole P2 grind to a halt.
    With 8 COG's I'd have expected being able to (re)start any cog is an important sales feature.

    You can always restart a cog. This has to do with restarting the central application.
  • rogloh wrote: »
    We now can't fully use the low memory for larger directly indexed tables if we want compatibility with SPIN2 and the clock frequency long storage. Not ideal but looks like we will just need to live with it. Any custom system independent of SPIN2 can still obviously fully use this memory for its own purposes at least, so all is not lost.

    TBH I don't think the low memory is very useful for tables. The main advantage of the low memory (below $100) is that it's directly addressable by immediate rdlong and wrlong instructions. The whole point of a table, on the other hand, is to look something up with a calculation, which would not be immediate.
  • Yep @ersmith, its advantage is when used for directly addressed lookup data using immediates which is a more specific case where this "table" index (from zero) is now really just the fixed address in the instruction. Mentioning using it for tables generically was not really the right term for what I meant.

    I sort of wonder what the low memory addressing benefit now is going to be when running SPIN2. I guess if more "system" type longs are defined they could go there, but any agreement will obviously be difficult...
  • jmgjmg Posts: 15,169
    ersmith wrote: »
    rogloh wrote: »
    We now can't fully use the low memory for larger directly indexed tables if we want compatibility with SPIN2 and the clock frequency long storage. Not ideal but looks like we will just need to live with it. Any custom system independent of SPIN2 can still obviously fully use this memory for its own purposes at least, so all is not lost.

    TBH I don't think the low memory is very useful for tables. The main advantage of the low memory (below $100) is that it's directly addressable by immediate rdlong and wrlong instructions. The whole point of a table, on the other hand, is to look something up with a calculation, which would not be immediate.

    I'd agree, and do languages even currently make use of the more compact HUB VAR access allocations ?
    Ideally, that needs a new memory segment (HUB_SHORT or HUB_NEAR or similar?) and because that space is 'community commons', a means to link across multiple languages is needed.
    That would allow mail boxes to be placed anywhere in that space, but users are going to need to be frugal in use.

  • Cluso99Cluso99 Posts: 18,069
    we at least have agreement ;)

    let me raise a possible alternative location for discussion....

    What’s in the top of hubram? I know there are some interrupt vectors there. Is there a place just below them for the clock free and clock Mode? This of course can be write protected too.

    Remember, the top of hubram is dual-mapped, but that is fine to address $F_FFxx or wherever.

    The ROM code may just not use all of this and there could be a sore slot or two.

  • evanhevanh Posts: 15,827
    Is it 1st of April already?
  • Chip, now is the time for us to work out these addresses which could be $04,$08 or $F8 and $FC even as it is still easily reached with un-augmented rdlong imediate. P1 Spin reserved the first 16 bytes anyway.

    My original addresses were mainly for some functionality and I always had the option of changing it later. This has nothing to do with the ROM though, because what's in ROM, stays in ROM.

    Yes @"Peter Jakacki" to the help.

    Thankfully Chip agreed on $14 and $18 that opens up a discussion about $4-$10 for other agreed Mailboxes, or not.

    why I think about Vegas right now?

    Mike
  • Cluso99 wrote: »
    we at least have agreement ;)

    let me raise a possible alternative location for discussion....

    What’s in the top of hubram? I know there are some interrupt vectors there. Is there a place just below them for the clock free and clock Mode? This of course can be write protected too.

    Remember, the top of hubram is dual-mapped, but that is fine to address $F_FFxx or wherever.

    The ROM code may just not use all of this and there could be a sore slot or two.

    I would really like to leave the top HUB untouched. it might change in future versions so placing something there is simply WRONG.

    But having some agreed upon mailboxes below $14 could make sense everything above $1A is free for the application/whatever

    Mike
  • Cluso99Cluso99 Posts: 18,069
    edited 2019-07-31 13:21
    msrobots wrote: »
    Cluso99 wrote: »
    we at least have agreement ;)

    let me raise a possible alternative location for discussion....

    What’s in the top of hubram? I know there are some interrupt vectors there. Is there a place just below them for the clock free and clock Mode? This of course can be write protected too.

    Remember, the top of hubram is dual-mapped, but that is fine to address $F_FFxx or wherever.

    The ROM code may just not use all of this and there could be a sore slot or two.

    I would really like to leave the top HUB untouched. it might change in future versions so placing something there is simply WRONG.

    But having some agreed upon mailboxes below $14 could make sense everything above $1A is free for the application/whatever

    Mike

    If you recall, the top 16KB of hub ($FFC00+) initially gets loaded with a copy of the ROM. We can optionally write protect this.
    This area is preferred for protected resident code, of which, interrupt vectors, code constants such as clockfreq, and other OS style routines such as SD drivers.

    So for me, this seems like the logical place to put clockfreq, but we would need to avoid overwriting TACHYON which lives near the top. Of course, once something is running (besides the booter, the monitor/debugger, or Tachyon, then this area is free for any use.

    FWIW, the my rom monitor/debugger overwrites Chip’s booter code for its input buffer (as agreed with Chip). And Tachyon copies itself down to hub $0, and thereafter its top hub ram is free for use.
    So, the only reentrant rom code that survives post boot is my monitor/debugger and SD code, although missing write commands (which is minor, but missing as there was insufficient rom space).

    BUT, I can live with wherever it is placed, as long as its there!
  • RaymanRayman Posts: 14,513
    I'm wondering if below $200 should be kept free for use as fast and direct hub access...
    This is where you can do a rdlong, for example, with immediate addressing.

    Between $200 and $400 is a strange place.
    Maybe system settings should go there...
  • RaymanRayman Posts: 14,513
    edited 2019-07-31 13:56
    Uh oh, now I've confused myself...
    If you do rdlong with a 9-bit literal, does that 9-bit literal represent a long or a byte?
    I think it's a byte...
    In that case, it's just below $80 that you can use literal addressing on...
  • RaymanRayman Posts: 14,513
    edited 2019-07-31 13:57
    Manual says " #$00..$FF - 8-bit immediate hub address".
    Why is it only 8 bits? Shouldn't it be 9?
    So, I guess it's only below $100 that you can do immediate, "literal", hub access on...
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2019-07-31 13:58
    rdlong immediate only uses 8-bits now (indexed modes) and hub is always byte addressed, whether that be bytes, words, or longs, so that means addresses $00..$FF where $FF can be a long from $FF..$102

    RDLONG from $FF address
    000F0: 5F 00 80 FD  1F 44 60 FD  60 00 80 FD  22 42 00 F6     '_....D`.`..."B..'
    00100: 1A 16 60 FD  21 16 60 FA  60 00 80 FD  24 22 60 FD     '..`.!.`.`...$"`.'
    00110: 1A 16 60 FD  21 16 60 0A  22 16 00 F6  FF 45 04 F5     '..`.!.`."....E..' ok
    TAQOZ# $FF @ .L --- $6016_1AF6 ok
    

    Where @ is a RDLONG..
    ' @  ( addr -- long ) Fetch a long from hub memory
    FETCH           _ret_   rdlong  tos,tos
    
  • RaymanRayman Posts: 14,513
    edited 2019-07-31 14:20
    Are you saying rdlong is 8-bits now due to the addition of indexed modes?
    Also, what does "where $FF can be a long from $FF..$102" mean?

    Ok, I think I see what you mean now with $FF..$102.
    If you read a long from literal hub address of $FF, that long stretches over byte addresses of $FF to $102.
  • cgraceycgracey Posts: 14,134
    Definitely, the place for CLKFREQ and CLKMODE is in lower hub RAM. The top 16KB of dual-mapped RAM needs to be free for debugger code.
  • David Betz wrote: »
    Roy Eltham wrote: »
    David Betz,
    PropTool is written in Delphi and uses some closed source libs or something. Porting it out to a reasonable language would be kind of silly. The better path to take would be to make something new from scratch using Qt. You can get a reasonable IDE up and running in Qt in a couple days, I've done the basics a couple times but then gave up because it was easier to just use VS Code or notepad++ for myself.

    There needs to be an open source cross platform IDE/compiler that is official, and it needs to be available at launch.
    Yes, a clean implementation would probably be best. I was just thinking that many people here seem to love the PropellerTool and it's simple enough that it might not be too hard to translate it from Delphi into C and use the Qt widgets to implement the UI. On the other hand, the fact that it's simple probably means recreating it from scratch wouldn't be that hard either. I don't suggest starting with either SimpleIDE or PropellerIDE though.

    I wonder, why the Delphi Pascal dialect is not considered a "reasonable language". Wouldn't cross-platform and open-source Free Pascal (https://freepascal.org/) and Lazarus (https://www.lazarus-ide.org/) be the first candidates to be looked at, when considering an update of a Delphi application?
  • evanhevanh Posts: 15,827
    By "reasonable", Roy probably meant unencumbered. I hacked up a FreePascal port of Chip's PX, which is also written in Delphi, for downloading the prop2 FPGA image files before realising I'd just messed up with Wine - it was working all along.

    Even without having ever written a line of Pascal before, the only challenge was finding and interfacing a suitable cross-platform replacement for the comport libs. I struggled with the comport error handling but got it working by ignoring that part mostly.
Sign In or Register to comment.